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

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

Answer 2

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

Answer 3

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.

Answer 4

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

Answer 5

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

Answer 6

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.