Which is more important? DB design or coding? [clo

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Which is more important: The design of the database? Or the design of the application code?

There is a lot of information out there about reusable code (from Carl Franklin at dnrtv.com, CSLA.net, et. al.), but I don't see too much information about Database Design and its impact on the life of an application (particularly how bad design decisions early on affect the application later in its 'life'.

Answer 1

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 2

In one sense, you cannot separate the two: DB design is coding -- it's just not coding in a procedural language.

However, I've worked with systems that had poorly-designed procedural software, and I've worked with systems that had poorly-designed database schemas (schemata?). In my experience, fixing the schemas is far more difficult due to upgrade and compatibility issues. I can imagine systems where this might not have been the case.

Answer 3

Depends one where you are in knowledge about both...and product requirements.

Neglect either side and your product could be in trouble.

That said, I tend to follow a DDD style of coding, where I define everything but my database first. That gives me a better idea of what data needs to be stored.

Then, once that is complete I can create and tune my database to suite.

Answer 4

Design if you're a DBM.

Coding if you're a programmer.

These aren't mutually exclusive and should both be well executed.

Answer 5

Both are just part of the implementation of that on which, of course, you spend the bulk of your up-front time - requirements and design.

Answer 6

It depends on your perspective. If you're a DBA then the db, if you're a developer than the code.

I've seen developers utterly abuse database with "bag" tables and i've seen DBAs create monsterous application code that is fine if you understand the structure of the database but opaque otherwise.

Ergo, both are critically important and if you're only experienced in the one you should get someone experienced to look at the other or improve your own skill set where it is lacking.