Re: Object-relational impedence

Eric wrote:

> On 2008-03-17, S Perryman <q_at_q.com> wrote:

SP>For the real-world systems involving "variant records" that I have worked
SP>on (100+ different record types, 100+ different property types) your table
SP>is merely a global variable from hell (as evidenced by the several telecoms
SP>systems that used the same approach in the 1990s and ended up being a
SP>lifetime rewrite and rebuild job whenever types and properties came and
SP>went) .

E>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).


E>If it is a given that you have to deal with, all you can do is treat it as

>>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.

Maybe they and I were in fact right.

>>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.

Feel free to search on "OSI network management" , "CMIS" etc. That will tell you sufficient about the subject domain for which they were using an RDBMS as an impl technology.

>>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.

Their system used an RDBMS. And it performed poorly. The same systems subsequently built on the same platforms (HW, OS, comms, prog langs etc) , but using an OODBMS instead, performed orders of magnitude better.

That's life.

> Does that sound even remotely sensible?

1. Sounds like the rantings of someone who cannot face the possibility that their pet thing was a problem.
2. So no, not sensible.

> I think they misused the tool.

The reality being that they did not.

> You may say they used the wrong tool - for this particular job.

They were constrained to use the wrong tool for the job. By their employer, and by no alternative commercial technology (OODBs etc) available at that time.

> Even if they did, that does not make it a bad tool.

No one said it was.

>>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.

Probably.
Fortunately there have been sufficient people to cogently debate with me.

Regards,
Steven Perryman Received on Tue Mar 18 2008 - 18:13:19 CET