Re: Flamewar object databases vs. relational databases (was: Unknown SQL)

>> >Pointers and OIDs are preferrably *not* visible.
>>
>> Actually, you cannot hide them completely. I thought that Lee already
>> covered this one with you. Just because the use cannot display a textual
>> representation of the OID does not make it invisible. The navigational
>> requirement implies that the OID is visible no matter how much you try to
>> disguise that fact.
>
>If there is no method to access the OID it is *not visible*.

If the product forces users to deal with them indirectly, they are still visible to the user. Code like: Parent.Child accesses an OID.

>Using navigation the user does not use or see any OIDs.

This is an untrue statement. They do use and do see the OID. They see it as a navigational requirement. You are trying to claim that because I have carpets, I don't use or see my floor.

>> > > How do I ensure that all of my users exercise the correct code?
>> > > If they
>> > > run last year's version, my company might not be in full compliance
 with
>> > > federal
>> > > statutes.
>> >
>> >By not allowing old versions to log in.
>>
>> In other words, I have to change all of my applications to use the latest
>> versions or the applications no longer work. In a relational system, I
 can
>> still run my older applications and I cannot avoid the current
>> constraints -- all without changing a single line of my application code
 or
>> even recompiling.
>
>In Java you use Jars and namespaces to allow exchanging libraries and the
>behaviour of programs by just copying one single file into the CLASSPATH.

This is irrelevant. It assumes that all of the required changes reside in the same source file. It assumes a single application to maintain.

>No, in a relational system, you cannot run older applications that are
>dependant on the existance of table x with column y.

Actually, you can. Have you never heard of views?

>Changing these in the
>application is...

Unnecessary.

> awful search-and-replace of strings without the help of the
>compiler.

...is not required.

>Because relational systems are so awful to maintain

Now I know it is intentional. You lie.

> older
>applications typically use old columns for new usecases

...in COBOL flat files.

>Instead of having
>meaningful table- and columnames, you often find separate documentation
 like
>"column drivers_license now contains the social security number".

...in COBOL flat files.

>You might
>also have views to do this.

Views already solve the original problem. Your suggested use, to implement a hackish kludge instead, is inappropriate.

>> >How many object databases did you test so far?
>>
>> Enough. I used to maintain the code for a proprietary network model
>> database as part of one of my early jobs.
>
>Early jobs?
>So your experience gos back to 1987?

Actually, my programming experience predates my working career; it goes back to 1981. Yes, my experience with using network model databases to store objects goes back to 1987.

>You might like to try some newer products.

Just because I started in 1987 gives you no reason to assume I haven't kept up on the state of the art. I have.

>Development does continue.

So? We are comparing two database management solutions. One is based on sound database management principles and the other is an unprincipled hodge-podge of ad hoc kludges and workarounds. Relational development will advance our technology. Network model OODBMS development will regress our technology.

These facts do not change.

>[Person, Employee Manager example]
>> >Why don't you supply the design that you would use?
>>
>> No such single design exists. There are innumerable designs I might
 choose
>> depending on the full set of requirements.
>
>Gee!
>Designing relational databases must be really difficult, if there is no
>rule, how to put this really simple design together

No rule exists in the object world either. You pulled a bunch of object classes out of your ass with no requirements. I could pull a bunch of relations out of my ass, but it wouldn't really be a design.

For instance, I could create a relation, Persons, with a single column drawn on the Person domain. I could create a relation, Employees, with a single column drawn on the Employee domain. I could create a relation, Managers, with a single column drawn on the Manager domain.

This is the exact logical equivalent of the object classes you pulled out of your ass. In most cases, I doubt that it is an appropriate design, but not knowing any requirements, I cannot say for certain.

>With Java classes it is
>all straightforward.

... but only to Java programmers. Apparently, your position is that your product is more powerful, more flexible and easier to use than relational model databases because it limits its use to a select group of highly trained programmers.

This is absurd.

>There is nothing to talk or think about:

This is a dangerously seductive statement. Programmers are required to think to perform their jobs.

>class Person
>class Employee extends Person
>class Manager extends Employee

Like I said, you pulled a bunch of classes out of your ass. Big deal.

>I would be very interested to hear about your "innumerable" designs.

Well, as innumerable suggests, there are too many for you to hear about them all. I suggested one above. You really just need to educate yourself on the basics.

>You must really have a hard time to decide on a direction to get going in
>practice.

You like to try to put words in peoples mouths. I have no problems choosing direction in practice.

>> >I was trying to point out that the choice of data model has an impact on
>> >performance.
>>
>> Well, it doesn't so you might as well give up now.
>
>Of course it does make a difference, if I place the above in 1, 2, 3 or
 more
>tables.

Due to physical independence, you can place the above in 1, 2, 3 or more tables and still have all the data stored in a single heap clustered in exactly the same manner. No difference in the physical store means no difference in performance characteristics.

>> >Outer joins are essential.
>>
>> No, they are not. Your statement is simply untrue.
>
>Where do you live and how simple are the programs you create?

And fuck you too, shithead!

Regards,
Bob Received on Sun Jul 22 2001 - 01:29:16 CEST