[
Lists Home |
Date Index |
Thread Index
]
Mitch Amiano <mamiano@nc.rr.com> writes:
> In working several years in business operations applications
> development with various SQL databases, it struck me that the
> relational model (a) wasn't actually followed by any
> implementations I saw
Yes, truly the theory is very different from the real life
implementations...
<snip/>
> Over the years, OO advocates chimed in with ad-hoc
> inheritance techniques which collectively they refered to as
> object models. Popular jargon somewhat obscured the
> orthogonal contributions of generic programming, templates,
> and architectural patterns, which more or less have been
> subsumed into OO culture.
Certainly true to date. However, I think this is becoming more formalized
and less ad-hoc. Again I hold out some hope for the model driven world and
the UML type efforts. I'm only partially a UML fan, but it does have well
defined relationships (though not necessarily in the mathematical sense).
> Even if you can map the constructs of an OO framework onto a
> particular relational database, it can't be automated because
> the *intent* is divergent. Well, the intent is mostly
> informal, unspecified, and floating free. The definitions of
> the system aren't themselves closed, at least not on the OO
> side.
I believe it is mostly possible to automatically reverse engineer a given
language (say Java or C++) into a UML representation? At that point you've
got abstractions which it seems are pretty much well defined and self
contained? You're right that you can't then map this to any arbitrary
pre-existing schema, but I don't see what is stopping you from generating a
new relational schema that can store all the given objects and their
attributes? Certainly Java CMP is one example of this (albeit perhaps an
ugly one). Maybe this gets back to the normalization issue: the result may
not fit with what a best practices relational model would look like, but it
should still work?
<snip/>
|
