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

Answer 1

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 2

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.

Answer 3

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/ffffd-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 4

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.

Answer 5

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.

Answer 6

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