That is more essential: The appearance of the database? Or the appearance of the applying code?

There's enough detailed information online available about multiple-use code (from Carl Franklin at, CSLA.internet, et. al.), however i aren't seeing an excessive amount of details about Database Design and it is effect on the existence of the application (particularly how bad design choices in early stages modify the application later in the 'life'.

Generally, Database structure is much more important, because it offers the structural framework which your code is developed. Generally (and YMMV quite substantially), refactoring your DB structure after finishing a phase of development is considerably harder than refactoring code which is dependent on the stable database. This is because simple refactoring your DB structure usually forces code changes overturn isn't true.

Basically, your code is dependent in your database a lot more than your database is dependent in your code. (If this isn't the situation, you may want to re-think your design.)

To deal with your edit I believe a lot of people writing / blogging about this kind of problem often come quite strongly in the "coding" aspect, these kinds of folks often consider database design to become trivial, and fewer interesting than coding interesting solutions. Basically, to somebody that loves to solve "tricky problems" (which is commonly those who blog more), the coding side is much more interesting compared to fundamental design issues. Even though the essential design issues aren't "sexy", they are very important (and Database Design is an extremely fundamental design problem).

Short answer: both. The chain is equally as strong because the poorest link.

If you're careless with each one you're condemned.

You DB design is most significant.

I am a coder, and that i prefer code, but ... should you ruin the DB design, your code is a nightmare. Your code will not are able!

Even if you attempt to refactor the DB design, you'll have a lot deal with code, that fixing everything is going to be overwhelming.

This is not a preference or perhaps a close one, it's greatly leaning toward the DB design being most significant.

EDIT: Even when you had been to possess key-value pair tables where everything got left in it, that will be a DB design according to business needs.

Paraphrasing Knuth -

It is much more vital that you make use of an efficient data structure. A poor structure will decelerate your application no matter your formula along with a good structure can even get rid of the need for several calculations.

I believe this is applicable equally to DBs. You're ultimately creating a massively linked data structure. If you do not make use of the right techniques, the application is going to be slow, no matter just how much chicanery you place in it.

Getting labored by having an appalling database design before, I have to put my hat within the database (or data model / ORM) design ring.

Meet up with many people knowledgeable inside your company/client concerning the problem area, and obtain all the data needed in writing, the audience it by logical areas, then you'll start developing an information model for you to become Objects, Database Schemas or perhaps an .xsd, etc. The items of information may have a title, a kind, maybe maximum length for strings, or perhaps be a collection or list or map of certain minimum or maximum capabilities.

Whether you design the database first following this, or even the OO model can be you, but a minimum of you've made an attempt to obtain a sane partitioned model in advance.

Actually within an MVC design, I'd classify the OO data model (classes in Java/C#) because the Model and inherently related to the database schema (with added transients and utility techniques obviously). Your controller - the "coding" inside your question - should certainly implement business logic while using model as symbolized through the objects you extract in the database using a DAO/ORM.

View it by doing this

  1. Altering the code means altering the code
  2. Altering the database will most likely pressure you to definitely alter the code too

Ergo you should obtain the database as stable as you possibly can as soon as possible