Re: Business Rules
Date: Thu, 27 Mar 2008 07:50:13 -0700 (PDT)
Message-ID: <fcaa6626-63f3-4c79-ac96-0d05bb810426_at_s13g2000prd.googlegroups.com>
On Mar 27, 5:22 am, Lars Tackmann <ltackm..._at_gmail.com> wrote:
> Hi
>
> This is a recurring question here, but I have read through the archive
> and failed to find a answer so here goes.
> Consider the following use cases:
>
> - When a customer purchases product A he automatically gets product B
> - Product C can only be bought with product A (either if you have A
> already or in the same order)
> - Product D cannot be bought with C
> - When you purchase X number of product type E then you can not
> purchase more than Y of product type F
> - A certain product combination (number and types) should yield a
> discount.
>
> as seen there exists the concept of a single product and that of a
> product type (family of products), the business rules should be able
> to work on both single products and on product types. The question now
> is how best to deal with such rules from a DB point of view, is there
> a relational design general enough to cope with such rules ? or do I
> have to resolve to stored procedures and constraints ?.
In theory, the any database constraint is an inequality
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In logical programming terms the partial order <= is the familiar implication symbol.
I suggest that any rule-engine technology that does not naturally embrace databases would give you the most headache. There is a reason why rule engines never being able to crawl out of their tiny niche and enjoy wider adoption. Received on Thu Mar 27 2008 - 15:50:13 CET