Class Design Vs Db Design (ER-Diagram)

Question

During the design phase of system development, should the class design dictate the design of the db, or should the db design dictate class design. I realize there are several situations where one or the other already exists and have to design the other around the existing. But say if you could start from scratch, which is a better approach? I'm leaning more towards Class Design first, then DB but would like some input on the idea. What scaling issues are there to consider? Implementation Issues?

Answer 1

Whenever it's up to me, I almost always start with database design.

If you have an incorrect or poorly designed program, you can always, at worst, throw away that one program and re-write it. But if you have an incorrect or poorly designed database, by the time you realize you have a problem there may be hundreds of programs using that database. Changing the database means at least studying every program that uses it, and serious database design changes may well mean heavily modifying every program that uses the database. Therefore, it is more important for your database to be well-designed than for a program to be well-designed.

Answer 2

Depends hugely on the application, I'd say. If your application is heavily data focused, you should favour the database over the application design; if your application is mostly about business logic or computation, you probably want to favour the application design.

Another consideration is the longevity and reach of the application - as Jay says, it's not unusual for more than one application to use the same database. Though I'd actually suggest that is a reason to provide a service or message based interface to the database - I don't think you'd want to allow multiple applications to have direct access to the data. In such a case, I think you'd focus your design effort heavily on the service layer.

You could also think about mapping the design to the business domain - ideally, you want your software to reflect business concepts (check out "Domain driven design" by Evans). This is usually - but not always - easier when working with object technology rather than entity-relationship models (the classic question is how to map inheritance to a database model).

Finally, it's important to consider the skills and inclination of the team - having a gang of database gurus design an object model usually leads to a steep learning curve (and vice versa).