Re: Object support in the relational model??

"Carl Rosenberger" <carl_at_db4o.com> wrote in message news:<ae5ee9$1lp$06$1_at_news.t-online.com>...
>
> Why do you criticise the approach of solving a simple task nicely
> and completely?

        First, because your posts in comp.databases.theory are trolling. You yourself acknowledge you don't care for theory, so why don't you go comp.databases.object? Has comp.databases.theory trolling got you many sales already, aren't you ashamed of misusing it?

        Second, we are not looking for 'solving a simple task', we're after a theoretically correct database. About 'nicely and completely', it's your evaluation, not yours. I've asked you already for examples about how your queries would compare even to SQL -- which we all know to be flawed --, and you haven't been able to produce anything convincing.

> Two examples:
> (1) Someone has written a parser in Java and he would like to persist
[…]
> (2) Someone writes a mobile Java application that is to run on

        You give only application-specific examples. They are worthless.

> a handheld with limited resources. By using a database engine
> that is written in Java and that directly understands objects and
> interacts with them, the application is much faster and much more
> efficient. Do you suggest to wait for the "ideal" relational
> database and for mobile systems with 250 MB of RAM before going
> productive?

        Faster and more efficient than what?

        You don't need to wait, I'm sure you are a much better coder than us and could, if you would but stop trolling around to study a little bit, produce something more relationally sound.

> You choose the word "gutter" for SQL, but why?

        Because SQL is frustrating, full of violations of the relational model that severely limitates its usefulness, including support for the object-oriented programming.

> How about providing a practical and production-ready replacement
> for SQL?
> This is what I do!

        Someone has already done it, Alphora Dataphor. But you haven't. Try using your server in all places where SQL now is. Try making it from an application-specific DBMS construction kit as all OODBMSs are into a generic DBMS server as SQL is at least half-way to be, Dataphor already is and its future competiting The Third Manifesto implementations will be.

> It is very easy to sit back and to laugh about the theoretical flaws
> in other peoples work without having to think about a *working*
> replacement. Java is flawed to a certain degree but if you want to
> make a living from selling software products, what are the choices
> but to use it?

        Java is a language. Use it, but use it to do something decent, as Alphora has used C# to create Dataphor.

> I am trying to produce the best product *for limited usecases* with
> the best knowledge that I have. Why do you think that you are in a
> position to look down on me?

        I wouldn't say I look down on you. I'm irritated at your insistence with trolling c.d.t with application-specific stuff. If at least you could keep your object stuff in c.d.objects and discuss real theory here.

> > BTW, what do you do with the end-user?
>
> It's up to application programmers to provide end-user products, right?

        Wrong. Real multi-user, multi-application databases are accessed directly to users, including to fix integrity issues because the data modelling was deficient and because the DBMS does not support all the integrity constraints it could, or because so much application logic is in methods, functions and other pieces of application code that it becomes impossible to enforce.

> I do think about the end-user by providing the application programmer
> with more ease to store his objects so he has more time to build a nice
> user interface.

        Not enough, as shown above.

> Noone prevents you from mapping objects to objects, to allow reuse in
> multiple applications. Noone prevents you from creating "object views".

        Yes, you do prevent. Because your object views can't really separate the physical and logical model. I've already asked you for examples, again you couldn't produce anything convincingly comparable even to SQL, much less Tutorial D.

> The SQL dialect implemented in the successful database products
> fails to store objects nicely, since it does not provide support
> for inheritance.

        That's part of the 'gutter' you question before. That's SQL fault, not a relational model one. That's what you should be trying to implement as others are doing right now. That's nicely explained in http://dbdebunk.com./ and in Date's books. Go do your homework.

> You can use classes (just for you: without methods) to represent the
> data model.

        Classes are types. What about relations? You fell into the First Great Blunder. How do you avoid OIDs and other kinds of pointers?

> You can use classes (just for you: with methods) to represent the
> logical model.
>
> You can use classes (just for you: without methods) to represent the
> physical model.

        I see you differentiate the data and the physical model. How do you do that?

> > You see, each OODB must be built from scratch on top of a
> > DBMS-construction kit, with minute attention paid to physical details.
> > Compare that with the logical model that can be implemented in a
> > RDBMS, and the physical details changed behind the scenes without
> > compromising the coherence of the user schema.
>
> I see.

        If at least you truly did.

-- 
 _
/ \ Leandro Guimarães Faria Corsetti Dutra        +41 (21) 216 15 93
\ / http://homepage.mac.com./leandrod/        fax +41 (21) 216 19 04
 X  http://tutoriald.sf.net./               Orange Communications CH
/ \ ASCII Ribbon Campaign against HTML email      +41 (21) 216 15 93