Re: Object-relational impedence

On 2008-03-17, S Perryman <q_at_q.com> wrote:
> Eric wrote:
>
>> On 2008-03-16, S Perryman <q_at_q.com> wrote:
>
>>>For the real-world systems involving "variant records" that I have worked
>>>on (100+ different record types, 100+ different property types) your table
>>>is merely a global variable from hell (as evidenced by the several telecoms
>>>systems that used the same approach in the 1990s and ended up being a
>>>lifetime rewrite and rebuild job whenever types and properties came and
>>>went) .
>
>> If you build a system around something like that, you are crazy.
>
> How *dare* you criticise the mighty "table-oriented" programming !!?? :-)

I don't know what table-oriented programming is, unless you want to bring up something like Filetab. Any tool can be misused, and this case certainly sound like extreme misuse (of just about anything).

>
>
>> If it is a given that you have to deal with, all you can do is treat it as
>> messages and parse them to put the information you need into sensible
>> structures. This is probably true for a much smaller number of variants.
>
> The system was just a nightmare (C, Oracle etc) .
> A relational *data* base was completely the wrong impl technology for the
> problem.
>
> And the developers could not be blamed for anything that they wrote (I saw
> the code) .

That just means that their idea of how to program with an RDBMS was similar to yours. Maybe you and they are both wrong.
>
> Their DB schema was normalised etc as expected (each type had a set of
> attribute properties, those properties could be sets, sequences, record
> types, collections of refs to instances of other types etc) .

Sounds like an EntityAttributeValue system - we _know_ that they are silly.

>
> The performance of the system (meta-type checking, property id retrieval,
> retrieving messages from real equipment and putting property info into the
> correct tables etc) was just dire as a result of the operational sequence.
>
> And this was for a system that only represented a manager-side view of
> a network of a few hundred equipment instances. If this approach had been
> used for subsequent systems I worked on (the equipment-side view, for a
> network of *500,000* telephone lines) , the developers would have been
> shot.
>
> It was such dis-crediting of RDBMS at the time (1991-1995) that led to the
> rise of OODBMS in the telecoms arena (at that time OODBs only had a foot-
> hold in the CAD/CAM arena) . The performance difference was orders of
> magnitudes.

Somebody designed and built a bad system, so you blame the tools they used. Oh, no, hang on, you just blamed one of the tools. All the other tools and platforms, all the designers and programmers, they were perfect. Does that sound even remotely sensible?

I think they misused the tool. You may say they used the wrong tool - for this particular job. Even if they did, that does not make it a bad tool.

>
> But as time has shown, the one thing that OODBs have not been good at is
> the routine application of relational expressions to an object base.
> OODBs gave us some goodies but not what IMHO is the most fundamental
> aspect of the Relational model.
>
> So there is a problem.
> Some of us need a relational "X" base, where X can be entities with data
> values only (ie the typical RDBMS) , and/or X can be objects with
> behaviour.

Understanding when to store an object as is, and when to separate out the data it contains, is one of the major problems for many OO people.

>
> What is required to get both, and the reasons why we haven't to date,
> have been (for a few here anyway) discussed as per the thread subject line.

It seems that a lot of the "discussions" have been people talking past one another because they have different frames of reference.

E. Received on Mon Mar 17 2008 - 19:57:07 CET