Re: QUESTION: List array, graph or network model support DB

David,

The only thing that the good Dr. Dweeb dislikes about your check list comparison is the fact that it is a check list comparison. I do not think such unweighted yes/no lists are particularly useful.

For example, was transactional DDL/meta-data versioning on your list ? This is astoundingly important from the DBA point of view and usually completely lost on journalist types and people who do not understand what it means (read almost all Oracle/SQLServer/Ingress DBAs).

The problem with lists is that they exclude more than they include and reflect the maker of the list more than anything else.

Oracle Classic is not on the bottom of my list of DBMSs by the way, but OracleRdb is definitely on the top. MySQL used to be on the bottom, but I think they recently discovered a transaction and might also have dicovered that "primary key != unique index" which may have elevated it a little.

Dr. Dweeb.

David Cressey wrote:
> Dr. Dweeb makes some good points. I agree that Rdb is a really sound
> implementation.
>
>
> As to whether DEC Rdb (Oracle Rdb) operates on relations
> or not, version one of Rdb/VMS when it was launched c. 1984,
> referred to "Relations" and not "Tables".
>
> That was before SQL became the lingua franca for data exchange in this
> environment.
>
> I once wrote a comparison on some 17 different points, between DEC Rdb
> (Oracle Rdb) and Oracle RDBMS.
> Dr. Dweeb isn't going to like this, but Oracle came out one point
> ahead, in my estimation. But most of the points I gave to Oracle
> were for programming convenience, and not for fundamental DBMS
> characteristics or DBA tools. In those areas, I think Rdb is better.
>
>
>
>
>
>
>> Costin Cozianu wrote:
>>> David Cressey wrote:
>>>>> if you mean by "ideal" that it runs on Unix and crashes all the
>>>>> time and needs a bazillion DBA's to keep them running and you want
>>>>> to constantly recover your database and your data files, then you
>>>>> can have ideal.
>>>>
>>>>
>>>> A little background on my original comment might be in order. I
>>>> don't tend to use the term "ideal" myself, much.
>>>>
>>>> I was referring to a comment made fairly frequently in this forum,
>>>> to the effect that "A commercial Relational Databse system has
>>>> never been built." These people exclude Oracle, SQL Server, DB2,
>>>> Informix, Interbase, yada yada, because all of them fail, in
>>>> one way or another to live up to the "ideal" of a truly relational
>>>> system. I have a hard time with such terminological rigidity,
>>>> myself. One can say that all those products aren't perfect
>>>> relational products, but one shouldn't, in my view, say that
>>>> they "aren't even relational".
>>>
>>>
>>> Why do you think that they are "relational" ? Do they operate on
>>> relations ? I don't think so. If their primary business is not to
>>> operate on relations but on bags of rows, calling them relational is
>>> misleading.
>>>
>>> Just like ODBMS are often database construction kits or persistence
>>> libraries, SQL DBMSes are a real DBMS (they do provide transactions,
>>> recovery, concurrency control, some data integrity) + a *relational
>>> construction kit*. Meaning that by a skillful use of SQL one can
>>> come somewhere close to a relational database.
>>>
>>> But the complexity is left on the user to shoulder, and it is very
>>> difficult to stretch SQL so that you are still in the realm of
>>> relational model. And guess what: most users don't and most users
>>> suffer as a consequence.
>>>
>>> It's even worse than that : very often product documentation and
>>> books sponsored by the vendors (Oracle press: anyone there ?)
>>> simply lie to the users by defining relational model in the most
>>> ridiculous terms. Actually they screwed up their products, they
>>> built a multi-billion dollars industry by taking agressive
>>> shortcuts on the implementation side and transfering the complexity
>>> to the user and now they try to lie and cheat by proclaiming their
>>> version of "relational" (not long ago the auto industry maintained
>>> seat belts and airbags were unnecessarily expensive and not needed).
>>>
>>> Best regards,
>>> Costin Cozianu
>>
>> Costin,
>>
>> You might do well to read the OracleRdb manual set. It can be found
>> on the Oracle documentation website. Start here
>> http://www.oracle.com/rdb/
>>
>> After you have read the several thousand pages here, you will may
>> want to understand the internals. For this you need to go to
>> training classes.
>>
>> Then you may be qualified to *attempt* to describe exactly where this
>> product deviates from the "relational model". You will of course
>> need to find out exactly which *version* of the model you mean.
>>
>> You will find that this product far exceeds all others in
>> "relational" compliance. On top of that it is probably the highest
>> performance engine on the market and has bells and whistles
>> management and deployment features which put it at the top of the
>> database food-chain.
>>
>> If you have a beef with SQL (and I think it has serious problems as
>> well), then take it up with the SQL standards committee. While SQL
>> has its faults, it is fundamentally "relationlal" and you comment
>> about "stretching SQL" to be relational makes no sense. Clearly you
>> have been using toy databases all your life and need a change of
>> scenery to more sophisticated implementations. (See reference above)
>>
>> Actually, your problem is the one shared by many - the inability to
>> distinguish between implementation and theory. Just beacuse some SQL
>> implementations are poorly implemented (toy databases), does not
>> mean that all of them are. Just beacuse some "relational databases"
>> are not really realational, does not mean that they all aren't.
>>
>> Finally, if you really want to see databases debunked by the experts
>> (you could learn something here), go to http://www.dbdebunk.com/
>> where the Chris & Fabian do sterling work. Sadly however, they have
>> not seen OracleRdb in the last 15 years either I suspect.
>>
>> Dr. Dweeb
Received on Mon Dec 16 2002 - 17:07:19 CET