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

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 2

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.

Answer 3

IMHO Good database design in more important then good coding (good coding is also important but compare to database design).

1. Simply because Database will store your valuable data.
2. Bad coding may not affect the database but will affect the scalability, performance of the whole application, etc. Over a period of time this can be fixed by refactoring(ofcourse some cost involved).
3. Refactoring a database is much more costlier and difficult.
4. Also normally we have multiple different apps running on same database so its a common factor.

Answer 4

I will not attempt to duplicate many of the fine comments made thus far. Nor will I spend any time identifying the dubious statements also made.

But I will add the following points.

If you are like most people you are referring to a RDBMS as the database in your question. An RDBMS is essentially a slave. It listens on a port and is duty bound to attempt to service all requests that come over that port. It has no way of know which of those requests are just plain stupid or ill-advised. Thus it is is easy for the most perfectly designed DB to be abused to the point of locking up the server. This implies that the code is more important. DBAs everywhere can be found pulling out their hair in response to some of the dumber things that app developers throw at the servers they manage.

So the best advice I can give you on the topic is to ensure that the DB is accessed by an API that is written by the same developer who designed the DB. Make it the responsibility of one dude (or one group reporting to the same dude) to ensure sound design decisions are made for both. If you're that dude, then don't skimp on one at the expense of the other. Design your API so that a refactoring of the DB can be done transparently to the clients of the API.

Answer 5

Maybe, I'm not very experienced in database design, but my feeling is : if your business classes are well designed, the only point where you access the databse is in your repositories (DDD speaking).

So a change in the database is just a change in the implementation of your repository. A bad database design will make your repository hard to code, and slow to perform, but it will not impact your business layer (90% of your code).

If you try to modify your business layer because of your DAO layer, why not to modify your business layer because of your presentation layer ? and then good luck to satisfy all constraint and good practices!

I think that both are important, but coding and database design should not be in the same hands. The more important for the developer is to isolate himself from the work of the db designer.(Even if the Db designer and the developer are the same person, you should not have to think about two thing at the same time)

Answer 6

I agree that both are critical, but there are substantial techniques you can use at the view, function, stored procedure level to make up for fairly horrendous underlying schema faults. On the other hand, if your coding is bad, short of fixing it of course, there's not much you can do at the design level to fix that.