CODEWITHSUNDEEP
database-designclass-design
Chad Harrison
Chad Harrison

Reputation: 2858

Class Design Vs Db Design (ER-Diagram)

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?

Upvotes: 4

Views: 992

Answers (4)

Neville Kuyt
Neville Kuyt

Reputation: 29629

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

Upvotes: 2

Matt Wonlaw
Matt Wonlaw

Reputation: 12443

Your database should be well thought out, but neither the application nor the database design should heavily impact the other. Your applications should be database agnostic. To store your application data you should rely on a layer that provides the necessary translations from your domain objects to database tables.

Upvotes: 1

Mike Sherrill 'Cat Recall'
Mike Sherrill 'Cat Recall'

Reputation: 95562

Should the class design dictate the design of the db, or should the db design dictate class design.

I'm not sure either should dictate the design of the other. Dictate implies tight coupling, which is generally a Bad Thing.

Database design assumes other programs will be accessing the database. An essential part of database design is choosing good table names, column names, and integrity constraints. All those things are parts of a database's public interface. (All those things are also tied up with normalization, a mathematically-based process that application development lacks. That's an observation, not a criticism.)

It's really, really expensive to change a badly designed public interface.

Upvotes: 1

Jay
Jay

Reputation: 27474

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.

Upvotes: 4

Related Questions