There are essentially two different approaches one can take when designing databases; these, from a high-level analytic point of view, narrow down to what is typically called “Top-down” and “Bottom-up” philosophies or methods.
While these methodologies can appear profoundly unique, they share the shared objective of joining a system by portraying the greater part of the association between the procedures.
Top-down
What is top-down approach to database design
Top-down design, is characterized by an extensive planning and research phase that leads into the development of the database (Maxey, 2012).
This is commonly used when first creating a database as a high level view of the entire database with all requirements are often known.
Advantages:
- A high level view of all components.
- Full visibility of what effect any change has on the entire database and relationships.
- More coherent, with less redundancy and fewer ways of doing things (Brower, 2015).
- Specify requirements without worrying about implementation.
Disadvantages:
- Quite a timely approach by comparison to Bottom-up.
- More communication is required between the designer and end-user of the database.
Bottom-up
What is bottom-up approach to database design
The Bottom-up approach starts with the particular points of interest and climbs to the general, higher level views later down the line.
To start a bottom-up plan, the designer will assess every one of the interfaces that the database has, checking tables, relationships and views. The designer will work in reverse through the database to figure out what information ought to be stored in the database and how (Burleson, n.d.).
This is commonly used when a database already exists but needs changes, new relationships or some sort of schema adjustment.
Advantages:
- Can quickly get something working and in operation.
- Critical modules tend to be designed and implemented early on.
Disadvantages:
- Do not always see the high level view of what a change can potentially affect.
- Likely more time spent due to requirements needing to be fleshed out a little more.
Which is better in my own opinion and why?
I personally like to use a combination of the two, with the beginning of a project favouring the Top-down approach with all amendments being undertaken with the Bottom-up approach; however, I do believe that one should design the database to fit the data, not the application. This important as one can get bogged down with implementation technicalities quite easily early on when all you should really be focusing on is the best way to store and retrieve the data in the fastest and less duplicative way possible.
A quote from Brower stays with me when he said that “management likes top-down to present the illusion of control; coders often prefer bottom-up, because they like their freedom, man.” (2015)
References
Maxey, K. (2012) Top-Down and Bottom-Up Design [Online] Engineering.com, Available from: https://www.engineering.com/DesignerEdge/DesignerEdgeArticles/ArticleID/5023/Top-Down-and-Bottom-Up-Design.aspx
Burleson, D. (n.d.) Top-down vs. Bottom-Up Object Database Design [Online] DBA-Oracle.com, Available from: http://www.dba-oracle.com/t_object_top_down_bottom_up.htm
Brower, D. (2015) What are the advantages and disadvantages of both top-down and bottom-up approaches to database design? [Online] Quora.com, Available from: https://www.quora.com/What-are-the-advantages-and-disadvantages-of-both-top-down-and-bottom-up-approaches-to-database-design
Gabot, M., A. (2014) Top-Down Vs. Bottom-Up [Online] Prezi.com, Available from: https://prezi.com/6wwqo-xbnk-3/top-down-vs-bottom-up/