i've read some interesting stuff about composite entity, wich i'd like to use in my app.
However, i couldn't find material on "how choose the best object to form the composite entity". All the examples are made with a few especific tables/objects predetermined.
In real life, in a big db, things are not that simple. I also read some material about the "object-relational impedance mismatch", but, anyway, I still need some advice on how to use the best groups of obects/tables to form the composite entities.
It is hard to give general advice, because the "best" choices depend on so many different parameters.
Here are the two rules of thumb I use:
1) Where possible, I make a one-to-one match between tables and entities. This is the most straight-forward approach.
2) Where the table data is too far removed from anything in the real world (which happens a lot with heavily normalized databases), I try to build objects that match logical business concepts. Factors I consider are:
a) Would the entity make sense to a non-technical person?
b) Will the queries used to populate entity data have reasonable performance?
c) Will the entity data be likely to be used as a unit (e.g. to populate a single screen)?
I admit that is vague, but it is the best I can do.
In the first option, you`re not really using composite entity, are u?
If u make a one-to-one mapping, you`re using ordinary beans (mapped one-to-one) to persist !?
That's right. The first rule is basically: "avoid composite entities if I can".
The other rules are: "if I can't avoid composite entities, here is what I think about".