Christian Neukirchen wrote:
> Interestingly, it can be shown that the Relational Model still is
> perfectly sound even if you remove the first normal-form (as opposed
> to all higher normal forms).

Yes. You just allow relation-valued attributes, and un/nest operators,
and you can easily define !1NF SQL. I have a paper somewhere which
studies this, and I believe it worked quite well. It also happens not
to break relational algebra or calculus at all. But that's not the
problem that needs solving, in fact it makes it slightly worse.

> The real problem IMO is not that we need a "OODB"...
> but they are hardly useful for expressing database
> operations).  It's clear to me that a good datastore will be based on
> the relational model.
> The real problem is its implementation at the moment, which
> constrains the developers a lot.

Yes. Relations are the right way to store data, objects are the
right way to manipulate them, but facts are the right way to conceive
of them, and hence to query them. Both ER and OO schemata are absorptions
of fact-based schemata to suit the physical characteristics of disk
storage and RAM storage/allocation respectively. IOW they're both
derived, to some extent contrived, for different purposes. Neither
can ever be the "one true way".

>   I argue that the following features
> would take a big deal of the pain usually connected with ORM without
> changing the validity of the Relational Model.
> * Dynamically, strongly typed values.  (Types can be enforced (or even
>   ducktyped!) by help of constraints.)
> * Dynamically defined relvars.
> * Dynamic fields.  (This is, in the end, dynamic relvars and DKNF).

What you are describing is a conceptual query language. Look at
ConQuer - not a lot of information about it is available, and
Microsoft owns (but appears not to be progressing) the only
implementation.

> The problem is not the Relational Model, but the current
> implementations of it: they live in a world that's very different from
> the one of a Ruby program.  Still, I argue that all three above
> features are consistent with the Relational Model.

Any absorption (clumping) of a fact-based schema obfuscates the
original intent. Each of the common types of absorption (ER and OO)
has its advocates, as we've seen in this thread. Can you please both
stop throwing rocks at each other and figure out how to get the best
of both worlds?

> That said, I honestly have no idea how to implement all this
> efficiently.  :-(

I do, and I'm working on it. Anyone want to help? Or are you happy
just throwing rocks?

Clifford Heath.