Re: Object-relational impedence
Date: Tue, 18 Mar 2008 17:13:19 +0000
Message-ID: <frot80$5k7$1_at_aioe.org>
Eric wrote:
> On 2008-03-17, S Perryman <q_at_q.com> wrote:
E>If you build a system around something like that, you are crazy.
>>How *dare* you criticise the mighty "table-oriented" programming !!?? :-)
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) .
> 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 asE>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.
> Does that sound even remotely sensible?
- Sounds like the rantings of someone who cannot face the possibility
that their pet thing was a problem.
- So no, not sensible.
> I think they misused the tool.
The reality being that they did not.
>>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.
Regards,
Steven Perryman
Received on Tue Mar 18 2008 - 18:13:19 CET