Re: Is it really that bad?

On Tue, 06 Mar 2001 17:01:21 -0500, Michael Wiik <mwiik_at_messagenet.com> wrote:
>Wow, I just came back from a frustrating meeting with a client's client,
>who's database I thought was just f'd up to the max, and realized after
>hearing their tech guy talk for a few minutes that he was trying to
>force an OO database from a relational one. I haven't been keeping up
>with RDBMS trends, and my main experience with RDBMS is 10+ years old,
>but I had no idea that such a bastardization was common. No wonder all
>the SQL queries, which should have been simple, were becoming hideously
>complex.

What were the issues, same as in the previous messages?

>Is there some reference that discusses this in detail?

Not that I've seen. All I've ever seen is people shouting at each other, OOP guys doing it with id's on every row, and relational guys calling them dopes. Guess what, the best design is somewhere between, leaning more towards the relational side. In my humble opinion, of course.

I keep hoping that some major vendor (Oracle, Microsoft, or IBM) will do a good job of adding OO to their product, and set a good model for everyone. Unfortunately, it doesn't look like anyone has a clue at Microsoft, and I can't even tell you what's going on with the other two.

--

The problems you see with these situations include:
a.  the data contains all of these arbitrary ids, it becomes hard to
develop with such hard to read datasets -- a not inconsiderable issue!
b.  since the pk is an arbitrary number, NOBODY EVER DOES THE DOMAIN
ANALYSIS TO FIGURE OUT WHAT THE REAL CONSTRAINTS ARE.  and even if
they do, declarative referential integrity probably doesn't work,
because you have to do joins back to the parent datasets, to see if
uniqueness constraints in the actual data are being violated.
theoretically you could still hand-code constraints as triggers, but
I've never even heard of it being suggested.  

Joshua Stern
JRStern_at_gte.net