Monday, November 26, 2007

Is the DB the chicken or the egg?

There have been a few discussions recently about whether it is better to design your new application by starting with the model or the database. Arguments about starting with requirements aside, it seems like the prevailing thought is that you should start with the model. I'm sure that this position seems like the logical approach to many programmers because of all the attention object oriented (like) programming is getting in the ColdFusion community.

I believe this to be a bit of a spurious argument. If you think about it, the model and the logical design of the db are two sides of the same coin. They both share the same primary responsibility of providing a programmatic representation of real world objects/entities. While the two are not perfectly aligned in implementation, they are extremely similar when looked at logically. Even our tools for representing them are so close as to be nearly indistinguishable to the lay person. Try putting a UML Class diagram and ER Diagram in front of a non programmer and see if they get any additional information out of one type of diagram or the other. The UML even uses a stereotyped class diagram as a tool to do database modeling (although it's not an official diagram type). We even have object-relational mapping tools to bridge the two.

I've heard the argument that the best one to start with depends on the project being undertaken. I would take this a bit farther and say that it's not so much the project being undertaken as the developer doing the design that should influence which one you start with. It all depends on your view of what these two things represent. If you think of your object model as the true arbiter of your business rules and the db is merely a persistence mechanism, then you probably should base your design on the model first. It's where you feel most comfortable translating your requirements into code. Building the db is something that you just have to do in order to persist your objects. It's grunt work.

If on the other hand, you think of the database as the primary store and final authority on your business rules and that the model is simply a communication mechanism (albeit a very robust one) necessary to support your view and controller layers, then starting from the db is probably a better approach for you.

Personally, I like to start with the db, only because to me, it feels like the "deepest" part of the application. I tend to think of the db as the foundation of an application. It seems more difficult to fix design flaws in the db than it does in the object model. It also feels like the db is slightly better at modeling real world entities simply by virtue of its persistence. Real world objects don't wink out of existence by falling out of scope, but that could be a discussion better had by philosophers.

That's my $0.02.

p.s.: Regarding the chicken and the egg question. I think that the chicken would have to have come first. My reasoning for that is that we define the type of egg by the animal that produced it. For example, if we have a hen's egg and a chuck-stritch comes out, it was and always will be a hen's egg. We couldn't have referred to it as a chuck-stritch egg since we didn't know what a chuck-stritch was until it hatched. If the chuck-stritch grows up and lays an egg, we'll always know that it is a chuck-stritch egg.

3 comments:

  1. I think we all begin with the model. You can't design the db without the model.

    Regarding the chicken and egg questions. Neither came first because a male and female would be required to procreate.

    ReplyDelete
  2. Many times I design my db without considering the model (in the mvc sense of the word).

    BTW, you don't need a male and a female to produce an egg. There is even some evidence that you don't need both male and female to produce a fertilized egg. Check this out: http://tinyurl.com/ytverf

    ReplyDelete
  3. Sorry if I was a bit vague in the original post. The discussions I've been reading are concerned with the MVC Model, not the business model.

    ReplyDelete