Re: RM's Canonical database
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 01 Jul 2006 17:55:01 GMT
Message-ID: <VFypg.112897$Mn5.28513_at_pd7tw3no>
> It was, I believe, David McGovern who said, "Databases don't
> store data, they store facts!" To be precise, I suppose he
> should have said "representations of facts."
>
> The point is that every tuple in every relation represents
> something that is true and the database represents the entire
> truth. Different applications with different concepts of
> truth require different databases - at least to the extent
> that their rules defining truth differ. These relations may
> all be held in the same "instance" or on the same "server"
> and some relations used by one application may be used by the
> other, but each has a different database. And declaring the
> constraints necessary to ensure the truthfulness of stored
> representations of facts for each can certainly be done in
> each database; there's no reason to throw up one's hands and
> say, "It can't be done in the database! We have to do it in
> the application."
Date: Sat, 01 Jul 2006 17:55:01 GMT
Message-ID: <VFypg.112897$Mn5.28513_at_pd7tw3no>
J M Davitt wrote:
> paul c wrote:
>> ...
> It was, I believe, David McGovern who said, "Databases don't
> store data, they store facts!" To be precise, I suppose he
> should have said "representations of facts."
>
> The point is that every tuple in every relation represents
> something that is true and the database represents the entire
> truth. Different applications with different concepts of
> truth require different databases - at least to the extent
> that their rules defining truth differ. These relations may
> all be held in the same "instance" or on the same "server"
> and some relations used by one application may be used by the
> other, but each has a different database. And declaring the
> constraints necessary to ensure the truthfulness of stored
> representations of facts for each can certainly be done in
> each database; there's no reason to throw up one's hands and
> say, "It can't be done in the database! We have to do it in
> the application."
I do believe it is more productive to talk of facts rather than data. For me that emphasizes that constraints are facts as much as extensions are, stating certain facts in a different 'representation' than the extensions do.
I don't know to what extent current products exploit this but clearly some optimizations to avoid accessing a large extension would be possible, eg., some queries or updates might be evaluated without reading 'user data'. It's hard for me to imagine a way to ensure all apps could exploit those constraints unless they are facts in the db.
p Received on Sat Jul 01 2006 - 19:55:01 CEST