What first model or database?

Asked 22/4, 2011 at 13:52 Answered 2/3 at 10:39

My question is about what should be go first in software developing: database model or domain model? Or these notion are parallels? Thanks.

Emulous answered 22/4, 2011 at 13:52 Comment(0)

It depends on whether you're a database or an object person. Each one would claim supremacy and say that their specialty should be done first.

I'd disagree with both. The first thing you should do is understand your problem well. The model and schema will flow from that.

You can't get rid of the object-relational mismatch impedence, no matter what you do. Objects are instance-based; SQL is set-based. You'll still have the problem.

Symptomatology answered 22/4, 2011 at 13:55 Comment(2)

+1 for pragmatism. The first model of the business domain should be on paper, not as SQL or some class definition. – Swordbill 22/4, 2011 at 14:2

Then after you understand the problem,I think it is good to work on the both at the same time, going back and forth between them. – Besnard 22/4, 2011 at 14:35

What should come first is the conceptual design (describing the problem domain in terms comfortable to the stakeholders), and the model is a logical design based on the conceptual design. There is a reasonably comprehensive set of tools and techniques for deriving an object model from the conceptual requirements. There are few commonly familiar tools and techniques for mapping from concept to schema design. (The only one I'm familiar with, which is a good one, is Object Role Modeling.) However, there good ways to use an object model to develop a schema. So I prefer conceptual to object model to data model.

Another way to view the question is that if you develop a database then the application tends to turn users into data collection agents serving the data model, losing the value of good requirements based on user stories and use cases (the second of which seem to turn into CRUD.)

Note: confusingly, ORM (Object Role Modeling is unrelated to ORM (Object Relational Mapping).

Frug answered 22/4, 2011 at 17:9 Comment(0)

Design good database and object models and leverage an object-relational-mapping (ORM) layer to solve the impedance mismatch (that's what they are designed to do).

Meddle answered 22/4, 2011 at 13:57 Comment(8)

Yes +1, design them independently (by separate people if possible), and then work on the ORM. – Glandule 22/4, 2011 at 14:2

No, ORM does not change the fact that objects are instance-based and relations are set-based. ORM just lets object modelers pretend that it doesn't exist. – Symptomatology 22/4, 2011 at 14:38

@Symptomatology - Of course an ORM does not change the differences between objects and relations. As you state it does allow object modellers to pretend the difference doesn't exist. So the if an ORM is used the answer to this question is that the object model and database model can be designed independently. – Meddle 22/4, 2011 at 16:55

Don't confuse pretending with reality. I chose the word deliberately. I think it's worth pointing out that stored procedures can also separate objects from schema and should be considered as another way to allow the two to evolve independently. – Symptomatology 22/4, 2011 at 17:13

@Symptomatology - Agreed an ORM layer does not hide 100% of the difference, but in reality they're pretty good (and getting better all the time). Also as you mention there are other strategies for keeping the models independent. IMHO that should be the goal, design the best models possible and leverage technology to move data between them. – Meddle 22/4, 2011 at 17:31

I think I'm ignorant about "getting better all the time." I'm not aware that Hibernate has changed much in quite a while, for example. Do you have a particular ORM solution in mind when you write that? – Symptomatology 25/4, 2011 at 9:24

@Symptomatology - In particular I was referring to JPA and the current spec JPA 2.1 (JSR-338). This Java EE spec is driven by a number of ORM solutions including: TopLink/EclipseLink (I lead EclipseLink JAXB) and Hibernate. – Meddle 25/4, 2011 at 13:6

Thank you, Blaise. I'm not aware of the evolution of TopLink (very old) or Hibernate (relatively stable). Can you cite substantial changes? Are they all part of JAXB? – Symptomatology 25/4, 2011 at 13:49

The answer will greatly depend on type of application you are developing and the languages/framworks you are using. If you will be writing lot of business logic in database (like Stored Procs, Views, triggers) then it makes sense to first design the database. If you are going to use some frameworks that map domain model to database (and possibly schema generation, like hibernate) then you will like to write Domain classes first.

Pathy answered 22/4, 2011 at 13:59 Comment(0)

This blood feud is older than pirates vs. ninjas. :)

In my opinion, and it is just that, starting at the domain model first helps to bridge that gap between the functional requirements and the technical design. The object model better represents the business data than a data model can, and they can be diagramed for better understanding by non-technical business analysts and project managers early in the project.

Pineda answered 22/4, 2011 at 14:0 Comment(3)

Funny I would say just the opposite. – Besnard 22/4, 2011 at 14:34

@HLGEM, I envy you then because the non-technical people that I work with couldn't make sense of a data model diagram to save their life. – Pineda 22/4, 2011 at 14:44

@Besnard Then you would be mistaken. – Consciencestricken 2/3 at 11:57

Pirates! Ninjas! Chicken! Egg!

Every project is different, and sometimes, the design of your database determines the success of your mission. It's quite rare, these days, because hardware and software has moved on - but if you have to store and compute huge volumes Of data, the schema may be one of your key concerns.

Most Of the time, the challenge is the business domain. I recommend "domain driven design" by Evans on that topic - but I'd encourage you to capture the business domain first, using use cases or user stories; turning those into software is the key challenge, and if you and your colleagues think best in entity relationships, go for it; if you're mOre comfortable with class hierarchies and responsibility diagrams, that's cool too.

My impression is that the industry is moving to objects, rather than tables - career-wise, that might be the way to go.

Twoseater answered 22/4, 2011 at 17:21 Comment(0)

The domain model presents a higher level of abstraction than that of the database model. The database model, on the other hand, adds a number of concepts that are harder to directly map to business concepts (e.g. pivot tables, foreign keys, views, etc). If you start by the database model you'll find yourself making a greater number of constraining decisions as opposed to starting with the domain model.

Consciencestricken answered 2/3 at 10:39 Comment(0)

Recommended topics

Hot tags