Re: Object-relational impedence

On 2008-03-18, S Perryman <q_at_q.com> wrote:
> 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
> E>messages and parse them to put the information you need into sensible
> E>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.
>
> Maybe they and I were in fact right.

I do not deny the possibility, I just assign it a low probability.

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

EAV is a way of misusing an RDBMS, and could be used for any subject domain - and your schema description sounds like EAV.

>
>>>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.
>
> What are you on about ?? What *other* "tools and platforms" ??

I am on about exactly what you say in the next paragraph.

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

This may demonstrate that the other tools were not a factor, but were the designers and programmers the same as well? And is there any way to demonstrate that their understanding of the two forms of DBMS was equally good?

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

It looks to me as if you made a comparison without considering all the factors, so it is obvious that I would consider that to be less than sensible.

>
> 2. So no, not sensible.
>

You misunderstand where I am coming from. "RDBMS" is not my "pet thing", though I have worked with them for over 20 years. And I do not believe that RDBMS is a universal tool that will solve all problems, nor do I believe that anything is!

>
>> I think they misused the tool.
>
> The reality being that they did not.

Not reality, just your opinion.

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

Thankyou.

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

E Received on Tue Mar 18 2008 - 21:19:31 CET