>
> - And there is another one discussed in the link I sent: have one big
> table with all attributes, and do entity inheritance, with superclass
> only mapped to a subset of columns, while each subclass can map any of
> the remaining columns. This is actually pretty cool for improving O/R
> performance, though wastes some extra space (very little indeed).
>
Yes, it is a very acceptable one except for those cases when you do not know
all the attributes and relationships of super and sub -classes from the very
beginning. Then when you add new columns later and they are constrained like
NOT NULL, etc. this is bound to break the existing code that is unaware of
the newly introduced constraints. But, otherwise it should work just fine.
>
> I guess you are right about INSERT and DELETE, though SELECT is pretty
> important. For instance I am doing this stats application (nhl.com) that
> has tons of statistics tables that have "to one" relationships to tables
> that are not "detail" and do not generally depend on the "master". For
> instance each stats record can have "many-to-one" to "player" and "game"
> records. They are read only and can be mapped as one big entity (though
> prefetching works OK too).
>
> So like I said to avoid extra mapping artifacts, we can map "flattened"
> ObjAttributes via underlying DbRelationships (I guess only "to-one"
> will qualify). Internally we will check if entities with such attributes
> are "read-only" or "read-write". You outlined the rules for this check
> above.
>
> So basically instead of "dependent-db-entity" in
>
> <!ELEMENT obj-entity (dependent-db-entity*, obj-attribute+)>
>
> I suggest to use:
>
> <!ATTLIST obj-attribute
> name CDATA #REQUIRED
> db-attribute-path CDATA #REQUIRED
> type CDATA #REQUIRED
> >
>
>
> (I hate DTD :-))
>
> "db-attribute-path" instead of being just a name of DbAttribute will be
> a path to destination DbAttribute via relationships (just like the path
> we use in expressions).
>
> Am I making sense?
>
Hate them too! :*) And yes, I think "db-attribute-path" is the way to go if
we make the distinction between "read-only" and "read-write" and accept
to-one relationships only, like you described. I am going to formulate and
publish the exact rules for the feature and start working on the
implementation asap. My only concern is we are going to change
"db-attribute-name" to "db-attribute-path" and break the existing data maps.
Do you think we should still support db-attribute-name in obj-attribute or
it is not really needed?
Andriy.
This archive was generated by hypermail 2.0.0 : Sat Mar 01 2003 - 09:19:42 EST