Re: The Practical Benefits of the Relational Model

Nathan Allan <member_at_dbfoums.com> wrote in message news:<1745087.1030481822_at_dbforums.com>... [large snip]

> -Concepts are well defined. There are not the gray areas found in OO...
> like which class to put a 'binary' method into, or whether to use a
> method or a 'write-only' property. How about the fact that the V-table
> is tied to the type, not the operator (so no future 'virtual' operators
> can be defined by someone other than the type designer).
I can hear a lot of advertising for Alphora which probably happens to be a good product and which - i know - is built around the Date/Darwen hypothetical D language. To be fair, however, you should not use the comparison with C++ (which i see shining through the above paragraph). C++ was defined for systems programming and is defined with strict criteriae regarding compatibility with C as well as performance. Let me respond to your specific criticism here: 1) Grey areas as to where to put a binary method. In practical life, these areas are not so grey at all. Very often, the answer is evident and in the few practical cases where they are not, C++ does provide you with the means to define your own multiple dispatch methods - and put your operator outside any class, which are for good reasons not part of the C++ language. Instead of extending the C++ language, the designers chose to provide a mechanism (templates) which allows the USER to extend the language, and this solution is the what is used to build - generically - such diverse stuff as vectors (arrays), lists and multimethods.Thus handling cases such as these is really a breeze, and you can implement them in a way that is most efficient for the case in hand. Let me refer you to Alexandriescus "Modern C++ design" for more information on such matters.
The hypothetical language D does support multimethods, but with a prize: grey areas otherwere. If you define operators OP(CIRCLE,ELLIPSE), OP(ELLIPSE,ELLIPSE) and OP(ELLIPSE,CIRCLE) the system is silent of which method that is called when you invoke it with two circle-parameters. C++ is defined very precisely and to force a solution on a problem such as above into a (ISO) standard would really be detrimental in many aspects.
2) Method/property:
There is no such thing as a property in C++. If you are referring to C# or some extension of the C++ language (which I believe you might be), it is true that you have a freedom of choice. Anyway, i do not see why this freedom should be a minus. In D you certainly also have these kind of choices.
3) V-tables:
I should mention that there is no such thing as a V-table in C++. The standard describes a model, not an implementation. 4) Furthermore I do not consider the relational model well defined - and certainly not in "The Third Manifesto".

[snip]

> -Specialization by Constraint and Generalization by Constraint. In
> English this means that I can treat an ellipse as a circle if the
> ellipse 'really is' as circle.

I must admit that this "Specialization by Constraint" stuff makes me a little nervous. How well thought of is this model? As a hint let me just ask you these questions:
1) Is RATIONAL a SUPERTYPE of INTEGER? If no, then why - this is perhaps the most evident place to have "S by C". If yes, is there then a difference in physical representation for these two types? 2) How do you perform integer division? How do you perform RATIONAL division?
3) If you declare a type COMPLEX, can you then declare it a SUPERTYPE of RATIONAL? If no, why? If yes how is the physical representation?

[snip]

> -"metadata" inference. In other words, it is possible, with a
> Relational implementation to no only know information like referential
> integrity constraints (FKs), keys, and other meta-data about base
> tables, but also about any arbitrary expression. This allows us, for
> example, to ask for the "default" column values of an arbitrary
> expression, or to know what the implicit references are of any
> expression. This also happens to be one of enabling factors for user
> interface derivation.

I do not quite understand the term "implicit references [...] of any expression". Could you please explain?

>
> -Well defined and formal "model" for type inheritance. This actually
> isn't a Relational thing because type is an orthoginal (apples and
> oranges) concept to the RM. I still think it is worth making explicit
> because it should be clear that OO doesn't have an exclusive on the
> concept. Well defined inheritance is beneficial because the SYSTEM can
> help us enforce domain constraints and such.
I do not see the connection here. Surely it must be possible to enforce constraints even if type inheritance is not used. Constraint enforcement is even possible (and easy!) in C++ - whether you use inheritance or not.

[snip]
>
> Now I should state that I use an OO programming language daily. As C.
> J. Date has pointed out, OO brought one... perhaps two good concepts to
> the table (neither of which are original but never mind):
> -User defined types (OOP encourages the practice)
Ahh - you must explain where user defined types then originated.
> -Type inheritance.
> OO is is not a "model" and is certainly not a data management solution.
What about generic programming.
This "OO is not a model" is often heard. However, in all the litterature that i have read about relational systems (including a few of Mr Date!), I have not seen ONE reference to a mathematical text-book or similar that is supposed to describe the relational model. Sure, relational systems are based upon set theory, but this alone does not in my opinion warrant all these model-claims. For one thing, the relational model has not considered the implications that computers are finite (and thus that precision is) very much. As for the model in "The Third Manifesto", I do not consider it a model at all. It is a very rough sketch, where much detail is left out and justifications for the prescriptions (and proscriptions) have no or little theoretical foundation. The model of inheritance is just one such place!

That said, I must hasten to add that I do like the relational model very much and that i agree with you on most of your other points. We just should not jump on the "third manifesto" waggon without a far more careful study of the implications of that model.

I have read elsewhere that you can provide us with a pointer to the Alphora documentation. I would be very happy if you could provide me with a copy to.

Kind regards
Peter Koch Larsen Received on Tue Sep 17 2002 - 09:39:32 CEST