Re: RM's Canonical database

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Sat, 01 Jul 2006 17:09:05 GMT
Message-ID: <R_xpg.7876$Eh1.4571_at_tornado.ohiordc.rr.com>


paul c wrote:
> Michael Gaab wrote:
>

>> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message 
>> news:44a63f88$0$31653$e4fe514c_at_news.xs4all.nl...
>>
>>> Robert Martin wrote:
>>>
>>>> ... business rules don't belong in the database.
>>>
>>> What, in your opinion, does belong in the database?
>>>
>>
>> Imagine that your database is used by multiple applications where
>> each application has different business rules. IMO, this is one reason
>> why one should not include business rules in a db. So the answer to
>> your question is *data*.

>
>
> I'm trying to imagine two apps that use the same data with different
> business rules. Wouldn't they screw each other? eg., one could leave
> the db in a state that didn't obey the other's rules?
>
> p

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." Received on Sat Jul 01 2006 - 19:09:05 CEST

Original text of this message