Re: The relational model is a wrong theory

From: James K. Lowden <jklowden_at_speakeasy.net>
Date: Mon, 28 Oct 2019 14:19:38 -0400
Message-Id: <20191028141938.db7a23110979df3876043f32_at_speakeasy.net>


[Quoted] On Tue, 15 Oct 2019 00:59:57 -0700 (PDT) vldm10 <vldm10_at_yahoo.com> wrote:

> Codd's database solution only stores the last attribute-level value.

Yes.

> This is the simplest case of a database solution.

Many would say still simpler solutions pre-exist even Codd, but OK.

> In that sense, I mean Codd's RM is the wrong solution. Codd's
> database solution has the following data operations: delete data and
> update data. This means that Codd's databases do not have past. And
> that is very bad for business. In the same sense, the ER is wrong.

(I think you mean "RM is wrong"?)

In your opinion, then, it's a mistake for the DBMS to ignore history, because businesses need to retain history in their databases.

OK. That's a point of view. I will say that only here among database theory geeks can we have a robust discussion about how SQL DBMSs are "bad for business" when the trend over the last decades has been for businesses to demand less, not more, of the DBMS industry, to say nothing of theoretical fidelity. I'm looking at you, NULL.

My question to you, Vladimir, is this: How is expressing time in the database theory -- and, presumably, language -- better than dealing with time overtly, as data?

In my world, if I have a table of people,

        create table people (name text not NULL primary key);

I can create people without a past (rather a neat trick). If they need a past,

	create table people (
		asof   date not NULL,
		name text not NULL,
		primary key (asof, name)
	);

serves the purpose. A view of "current people" is easily created,

	select * from people as P 
	where not exists (
		select 1 from people 
		where asof > P.asof and name = P.name
	);

You seem to want to make the history of people intrinsic in the language. Obviously, that makes the language more complex, because it has to express a new dimension, namely time. For that language to be "better" in any sense, it has to enable simpler, shorter queries than otherwise possible with simple old SQL. Can you provide an example?

--jkl Received on Mon Oct 28 2019 - 19:19:38 CET

Original text of this message