Re: Object-relational impedence

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

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

> >>>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 Wed Mar 19 2008 - 14:16:34 CET