Re: Object-relational impedence

From: Brian Selzer <brian_at_selzer-software.com>
Date: Wed, 19 Mar 2008 00:34:18 GMT
Message-ID: <ecZDj.21736$0o7.14383_at_newssvr13.news.prodigy.net>


"S Perryman" <q_at_q.com> wrote in message news:frot80$5k7$1_at_aioe.org...
> 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.
>
>
>>>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.
>
> What are you on about ?? What *other* "tools and platforms" ??
>
> 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.
>

Funny, but this "orders of magnitude better" claim sounds like something a shifty politician like Barack Hussein Obama would say. He can supposedly turn a whole lot of nothing into something that makes women swoon. Politicians--especially Dimocrats, but not exclusively--play on the ignorance of their constituents by telling only part of the story. Take for example the hysteria over global warming. The disasters and horrors that are predicted by the left-wing lunatics can only happen if the globe warms by at least 5 or 6 degrees, but in the last 100 years, the globe has only warmed by about half a degree. I once altered a system that was designed to process only 14,000 transactions per hour so that it could process ten times that in the same time. That's orders of magnitude improvement, but I didn't change the DBMS, I rewrote some poorly written procs. I once altered a system that had a job that was taking over 25 hours to process so that it took less than 30 minutes by simply adjusting the way the hardware was used. Again the orders of magnitude improvement was not due to changing the DBMS, it was making the best use of the available hardware. It is also often the case that you can obtain orders of magnitude performance improvement by simply adding an index--at least for queries that can take advantage of the index. Your claims of orders of magnitude better performance, therefore, are much like the claims of a used car salesman, or of a sleazy lawyer. Suspect.

>
>> 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 Wed Mar 19 2008 - 01:34:18 CET

Original text of this message