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


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


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.


Having worked with an appalling database design before, I must put my hat in the database (or data model / ORM) design ring.

Get together with some people knowledgeable in your company/client about the problem area, and get all of the data required on paper, the group it by logical areas, then you will start forming a data model which you could turn into Objects, Database Schemas or an .xsd, etc. Each item of data will have a name, a type, maybe maximum length for strings, or be a set or list or map of certain minimum or maximum capacities.

Whether you design the database first after this, or the OO model is up to you, but at least you made an effort to get a sane partitioned model up front.

In fact in an MVC design, I would classify the OO data model (classes in Java/C#) as the Model and intrinsically linked with the database schema (with added transients and utility methods of course). Your controller - the "coding" in your question - should really implement business logic using the model as represented by the objects you extract from the database via a DAO/ORM.


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


The domain model should be independent of persistence implementation details (although the technology does place some constraints on the model) â€" http://www.infoq.com/articles/ddd-in-practice

You should focus on the domain model. With great ORM technology like Hibernate/NHibernate the database will only be an implementation detail.

Books you should read if you are doing .NET web development:

  1. ASP.NET MVC Framework Preview (only 100 pages, and will get you started)
  2. NHibernate in Action
  3. Domain Driven Design and Development In Practice (not read it, but I will, and it's free)
  4. Refactoring: Improving the Design of Existing Code


It has been my experience (and I've been involved in fixing database problems for around 30 years and have dealt with hundreds of different databases) that all too many of the problems in database performance are from the inappropriate attempts to reuse code. Functions are far slower than inline code. Cursors reusing a stored proc that inserts one record at a time are far, far, far (light years) slower than set-based code. Reusing a proc that gives back what you need and ten other fields is wasteful of server and network resources. Using an existing view that joins to ten tables when you only need information from three of them is wasteful of server resources. Code reuse in databases is not nearly as good a thing as it is in other places. This is not to say that code shouldn't be reused if need be. Just that it should never take precedence over performance. Databases are unfortunately not well designed to reuse code. Most databases are not object oriented and object-oriented thinking in designing or accessing them will often result in a poor design.

Before you can even think about code reuse, you need to have a rock solid normalized database design. You need to think about how you will be extracting as well as inserting data into the database. You need to think about how well will this work once there are many users and records because redesigning a basic database structure at this point often becomes too expensive and time consuming. It is often far easier to refactor the application code than the basic database structure and, far too often, the database refactoring does not get done. If you change the table structure to go from a denormalized table to a parent child structure because you find out the current structure isn't suiting your needs, then you may end up changing hundreds or even thousands of queries against this table. This is why it is important to spend a lot of time on database design, you won't get the chance to revisit it later due to time/money constraints. If you think of the database as the foundation of the house and the application code as the structure you will see why this is true. It is far harder to change the foundation with the structure on top of it than it is to move the internal walls. Databases and the applications which access them are the same way.


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.


I don't think you can separate the two in the manner you are describing. One will invariably influence the other. For example, a solid database design that is easy to maintain and performs well will mean fewer code changes. Well architected code and a strong understanding of your use-cases will lead to a neat and maintainable database schema.

For my money, I would spend more on a solid business layer and build my database to support it, but that is my knowledge bias.


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.


I can see I'm going to be swimming upstream, but I'm pretty strongly biased toward software being the answer to your question.

While your software can adapt to a weak schema, there's not much your database can help you with if your software is disfunctional. I've had a couple cases where I've been able to take a popular front-end application and totally rebuild the database without serious disruption, because the users don't see the database directly. (Which won't be true if the software is crap.)

So I'd say pay attention to what's closest to the user first.


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.


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.



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


They are not mutually exclusive. Both must be rock solid to have a chance at a rock solid solution.


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.


If you are unsure of your skills in either area then do your best to seperate the two as much as possible. The worst scenario is writing a tangled mess that can't be easily corrected or maintained later.


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.


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.


Both are important of course, it's a symbiotic relationship.

But if your DB is jacked, no amount of good code can make your app shine.

However, if your DB is really good, then good code can make it even better (but bad code can still ruin it).


we've re-written the website 3 times in 4 years. the database hasn't changed. (well, a little)


Design if you're a DBM.

Coding if you're a programmer.

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


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.


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)


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.


Both are important but poor design in any of the upstream activities are generally more difficult to correct. Changes to the functional specs for example will naturally generate a lot more work then some verbiage changes on the interface.

Any meaningful changes to the database generally require coding changes as well, so I personally spend a lot more time agonizing over database design decisions then coding decisions (although I'm sure I'm not the only one who has spent an hour or two trying to find the perfect name for a class).


A database is an artifact of a computer program that models a given process and system

Ideally it should not be of any concern

Current object persistence technology is not quite there yet, so it probably will be some of your concern for some time to come

The question is: What is the database there for?

If it is there to persist the objects in your model of the processes and systems then you shouldn't have much to do with it

If it is there to fix holes in your model then you will spend a lot of time on it


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.


Depends what you enjoy of course, but the future is toward abstracting away the data layer -- that is, considering the data store to be an implementation detail rather that the core of the app.

You'll hear the term "persistence ignorance" in certain circles. The goal is that the domain model (business entities) are designed without knowing how the data will be stored. Behind the scenes, it may be in SQL, AmazonDB or XML.

If you enjoy DBA stuff, that's where you should be. But if you want to be more on the application side, get to know ORM frameworks.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »