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

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.

Answer 2

Short answer: both. The chain is just as strong as the weakest link.

Answer 3

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.

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

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

Answer 6

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.