Re: Object-relational impedence

On Mar 19, 2:14 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> David Cressey wrote:
> > "Eric" <e..._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.

Hmmm, isn't that we normally call singletons these days...?

>
> 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 - 17:04:46 CET