Which is more important? DB design or coding? [closed]

Answer 1

Neither is unimportant, but...

Bad database design might make writing good programs impossible. Also, you can usually rewrite bad code but if you have lots of data in the database, you just have to live with the bad decisions made in design phase.

Answer 2

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).

Answer 3

Short answer: both. The chain is just as strong as the weakest link.

Answer 4

Look at it this way

1. Changing the code means changing the code
2. Changing the database will probably force you to change the code as well

Ergo it is important to get the database as stable as possible as early as possible

Answer 5

It depends on what is important to your business. Ideally, you shouldn't short change either, but if you must, you should also ask yourself this question:

Is your application there to handle data, or does the data transcend your application?

In other words, if the code part of your application blew up today, but your data is still there, how bad of a disaster would it be? If you answer is:

I can always write the code to replace the app, but without the data, we're doomed.

Then you had better make sure that your data is sound, because it will probably outlive any code you write today. That's not to say you shouldn't put a great amount of effort into writing a solid codebase, but the code is ultimately transient whereas your data is not. If you're stuck with bad code, you can rewrite, but if you have bad data, it will likely have much broader implications.

On the other hand, if the data is really only there to make sure that your code works well, and the code itself is more important (the inverse of the above scenario), you should ensure that you have a good codebase, and revisit any deficiencies in the data later.

EDIT

In most enterprise applications, the data are far more important. I have worked on conversion projects in the past where the code was far past its life, but migration was delayed for so long (sometimes decades) because the data was so bad that it took a significant and very discretionary effort to get the data to a point of health where it could be migrated.

Answer 6

Both

Great code can be ruined by a horrible db design and a great db design can be ruined by horrible code.