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

Answer 1

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

Answer 2

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 3

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)

Answer 4

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.

Answer 5

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.

Answer 6

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.