Re: The Foundation of OO (XDb)

"Clifford Heath" <nobody_at_nowhere.net> wrote in message news:3D0DB42E.9DCAF907_at_nowhere.net...
> Bob Badour wrote:
> > > my data models often need to support
> > > specialisation, and though it doesn't break the relational model at
all,
> > > the products don't support it natively.
> > Specialization of what? Why do you think views fail to support it?
>
> Views do support it, but not IMO as conveniently as possible. I'm not
asking
> for extensions to the relational model, just for some higher-level
structures
> for convenience and aspect-separation.

Those so-called "higher-level" structures fundamentally alter the model! You are not asking for extensions--you are asking us to throw it out entirely.

> All the operations are still well
> defined in terms of relational algebra.

That's something you will have to demonstrate. Shorthands are perfectly acceptable provided they do not seek to violate any good principles and meet some need.

> Also, placing additional data in joined tables may not produce the most
> efficient physical model

The physical model is completely independent of the logical model. The dbms does not need to physically store data as tables in order to so represent the data to users.

> - the DBMS may know (either by sampling or by
> being told) that 90% of the elements in A have additional attributes in
> B, and that the overall best physical storage compromise is to store the
> additional attributes of the B tuples with the B records. This could be
> easily supported by physical pragmas, e.g.:

This is irrelevant the logical data model and requires no change to the logical data model.

> > Foreign key constraints are quite simple. If your constraints are
complex, I
> > suggest you need to reconsider your data model. If it turns out that the
> > application domain is just complex, the complexity may be inherent in
the
> > problem.
>
> I think that the complexity *is* inherent in the models I'm speaking of,
but
> a greater difficulty comes when deciding what types of constraints are
relevant
> to specialisation, and in finding a language to represent those
constraints
> that communicate clearly and succinctly with its users (SQL it aint!).

Of course not. SQL sucks and is collapsing under its own weight.

> But I
> haven't really pursued this much so perhaps it's not as hard as it seems.

Have you read Date's and Darwen's _The Third Manifesto, Second Edition_ ? They describe a sound model of types and type inheritance.

>
> Clifford Heath
Received on Mon Jun 17 2002 - 20:07:04 CEST