> " A relational model in a database is not something
> cooked up over
> a dinnertable, it's the result (!) of an abstract model like
> a NIAM/ORM model. In there you define entities, like customer
> and order, and define relationships between them. These
> relationships aren't there just because some moron thinks
> they should be there, they are there because these entities
> have these relationships. This means that EACH instance of
> these entities have these relationships. "
>
> Come on, Frans. You know, at your level of experience, that
> the physical model of a database is often very different from
> the logical one. He's saying that it's sometimes the case
> that someone builds a database first and the application
> after, and that the data structures often then mirror the
> table structure. He's right! I've seen this very thing in
> practice. Think of a structure with lots of mapping tables,
> and a special object created for every one of those links,
> because some developer thought it was a good idea to create
> class AToBMap to mirror table a_b_map. Yet a mapping table
> is usually the simplest and best way, and often the only way,
> to represent a many-to-many relationship in many RDBMSes.
but many many-to-many relationships are objectified. See for
example the Order - Product M:N relationship, over orderrow. Or
department - employee which has a 'datestarted' field. These m:n
relationships require a 3rd object. Now, when an m:n relationship is
suddenly objectified, it pops up in the open. Why is that? After all,
the m:n link table IS an entity, by definition of the relational model.
Admitted, often it is dumbed down as 'not important' and is hidden away,
but this can often lead to trouble once a table with solely FK fields in
a combined PK is suddenly equiped with a non-pk mandatory field. A lot
of code will break where you wouldn't expect it.
Often people want to persist a complete object model in a total
different relational model and wonder why the O/R mapper is so darn slow
or why it is so complex. It's not complex, it's simple, you should do
what needs to be done to implement the functionality to implement, not
do what you think is required to create the most beautiful oo tree in
history just because you can :)
> Not only that, but even without normalization,
> denormalization, bad design in the database (ever have to
> write an application that used an existing bad structure?),
> etc. it is often natural to implement many complicated things
> differently in database and object form. Things aren't
> always as simple as we'd like to be.
Legacy stuff is a problem indeed. Bad designed relational
models, databases with tables without a PK but with a UC :D. If these
bad designs are included in the code, you have two times the trouble.
I doubt however if you can make this misery any less bad for
your project when you're including a layer which allows you to create a
complete different object model with apparently no logical connection
(exxagerated) with the database model. You then run the risk the OO code
is also unmaintainable in the end because yuo need a lot of in-depth
knowledge where which data is stored, why that FK constraint is throwing
an exception when you want to write a hierarchy to the database etc.,
when you want to update that code after, say, 6 months of not working on
it. :)
FB
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
