A good database design is, therefore, one that: Divides your information into subject-based tables to reduce redundant data. Provides Access with the information it requires to join the information in the tables together as needed. Helps support and ensure the accuracy and integrity of your information.
The information requirements are the most important part.
MySQL, Oracle, PostgreSQL, Microsoft SQL Server, MongoDB, Redis, Elasticsearch, Cassandra, MariaDB, IBM Db2.
Generally, Database structure is more important, since it provides the structural framework on which your code is developed. In general (and YMMV quite considerably), refactoring your DB structure after completing a phase of development is significantly harder than simply refactoring code which depends on a stable database. The reason is simple; refactoring your DB structure usually forces code changes; the reverse is rarely true.
Quite simply, your code depends on your database more than your database depends on your code. (If this is not the case, you may need to rethink your design.)
To address your edit; I think a lot of folks writing / blogging about this type of issue tend to come quite strongly from the "coding" side of things, these types of folks tend to consider database design to be trivial, and less interesting than coding interesting solutions. Essentially, to someone who likes to solve "tricky problems" (which tends to be the people who blog more), the coding side is more interesting than the fundamental design issues. And while the fundamental design issues aren't "sexy", they're extremely important (and Database Design is a VERY fundamental design issue).
Short answer: both. The chain is just as strong as the weakest link.
If you are careless with either one you are doomed.
You DB design is most important.
I'm a coder, and I prefer code, but ... if you screw up the DB design, your code will be a nightmare. Your code won't have a chance!
Even when you try to refactor the DB design, you will have so much work around code, that fixing it all will be overwhelming.
This isn't a preference or even a close one, it's very much leaning toward the DB design being most important.
EDIT: Even if you were to have key-value pair tables where everything got dumped into it, that would still be a DB design based on business requirements.
Paraphrasing Knuth -
It is far more important to use an efficient data structure. A bad structure will slow down your application regardless of your algorithm and a good structure can even eliminate the need for certain algorithms.
I think that this applies equally to DBs. You are ultimately building a massively linked data structure. If you don't use the right methods, your application will be slow, regardless of how much trickery you put into it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With