Re: RM's Canonical database
Date: Sat, 01 Jul 2006 21:24:03 GMT
Message-ID: <TJBpg.110859$iF6.88018_at_pd7tw2no>
paul c wrote:
> Marshall 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*.
>>
>> [speaking in terms of the enterprise dbms]
>>
>> I reject your argument on simple definitional grounds.
>>
>> Given a business with a set of applications A and a database
>> D managed by a dbms M.
>>
>> Consider a given rule R.
>>
>> If for all a in A R holds, then R is a business rule, and should be
>> managed by M.
>>
>> --otherwise--
>>
>> If there exists a in A where R holds, then R is an application rule
>> and should be managed by a.
>> ...
> > Now along comes app A2 where R also holds. Can A and A2 somehow share R? > > I wonder if this definition is incomplete in that it doesn't say what > happens with D. > > p
sorry, i might've mangled your notation a little, let me change that to "app a2 where R holds for a1 and a2".
(i also imagine it would be smart from an optimization point of view to be able to segregate R somehow, so that app a3 doesn't have to bother with R. i guess that would involve including d1 and d2, meaning the relations mentioned by a1 and a2, and their constraints, without mentioning a1 and a2. for example, is it possible to write constraints in a way that would let them have foreign keys? maybe nonsense, just thinking out loud.)
p Received on Sat Jul 01 2006 - 23:24:03 CEST