Re: Object-relational impedence

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 19 Mar 2008 11:14:31 -0300
Message-ID: <47e11fcc$0$4055$9a566e8b_at_news.aliant.net>


David Cressey wrote:

> "Eric" <eric_at_deptj.demon.co.uk> wrote in message
> news:slrnfu08uj.bia.eric_at_tasso.deptj.demon.co.uk...
>

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

>
> I don't understand what "your schema" refers to. Are you referring to
> Perryman's schema, or to the schema of the relational database as it stood
> when Perryman began work?

A schema description is a description not a schema. Perryman described a schema. In part, he described it as a global variable from hell.

I am not sure how Eric gets from there to EAV, and I think that's highly speculative on Eric's part. I also note that Perryman's anecdote demonstrates nothing useful or relevant. The sorts of idiots who think network model databases are the cat's ass are the exact same idiots who invariably screw up relational designs beyond all recognition.

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

>
> On several occasions, I've come in and improved performance by factors of
> up to 60 to 1, but without replacing the relational (well, SQL) with an
> OO centric application. Just doing things like defragmenting disks,
> correcting the indexes, and good mapping between data and disk spindles can
> result in a 10 for 1 improvement. And all those steps are shielded from the
> application by physical data independence.
>
> So, without claiming that Perryman didn't perform a valuable service, I am
> going to claim that in many situations, the problem is NOT one of moving
> from a relational model to an OO model, but one of moving from bad database
> management to good database management.
>
> Bad database design can cause even worse consequences than bad database
> management. Moving from bad database design (such as EAV) to good database
> design can produce even more dramatic improvement than my work that I cited,
> but at a much higher cost in reengineering effort.
>
> And, while the cases I've cited are about improvements in speed,
> improvements in flexibility can be even more important. It's easier to
> measure the success or failure of efforts to improve speed.

[the above not snipped as it bears repeating]

[snip] Received on Wed Mar 19 2008 - 15:14:31 CET

Original text of this message