 | |
#71
 
| |||
| |||
|
Re: Business Rules -
05-23-2008
, 06:39 AM
|
Lars Tackmann 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 ?. I would rephrase the question to ask if you've come up with a concrete table design that can hold these options. Are they hypothetical, or are these the actual requirements for a real system? The first looks like a cross-reference from products to products, no? So that is easy enough to store. An insert or update trigger that queries the table and adds more lines (unless already present) should not be that hard. The second, if I am not mistaken, is identical to the first, except that it requires the user's consent to purchase an additional item? Otherwise it would be the same as the first one. The trick would be that it looks in their sales history to satisfy the behavior. Again a simple cross-reference table stores the rule, a small trigger implements it. The third rule is again another cross-reference. Maybe all three kinds of rules are in the same table with a column to say the rule type. The fourth rule is starting to sound like you're making this up, but I don't know what business this is in and I've seen some strange ones, so I suppose it must be real. This looks superficially like a super-case of rule 3. Adding quantities to the cross reference causes rule 3 to reduce to a case of this rule. For the last one, one way or another you have to query quantities and group by product category. You can do it in a view, in SQL in a trigger, or anywhere else. I am not on the lookout for a complete solution, I simply see allot of business rules like the ones defined above, but never a clean solution to maintaining them (perhaps a DSL or a rule engine is the way to go). Any feedback will be greatly appreciated. -- Yours sincerely Lars Tackmann |
as a possibility.
Some databases I have worked with distinguish between "parts" and
"products". A feature of a "product" is that is can be sold and bought.
Products consist of one or more parts. parts may contain other parts, and
so on. Services, like the right to attend a given offering of a given
course, may be included in "products" by including parts that are
intangible.
The rules you have suggested such as prerequisites and mutual exclusions,
apply to the formation of groups of parts... and not to the formation of
collections of products. In such a framework, the fact that a given person
is buying two pills that should not be taken together is a relationship
between parts, not a relationship between products.
And, in reality, the problem there is not that person X is buying two
pills. It's the likelihood that the same person will swallow both pills.
That would be true even if the person stole the pills, or made one of them
himself.
#72
| |||
| |||
|
|
Lars Tackmann 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 ?. I would rephrase the question to ask if you've come up with a concrete table design that can hold these options. Are they hypothetical, or are these the actual requirements for a real system? The first looks like a cross-reference from products to products, no? So that is easy enough to store. An insert or update trigger that queries the table and adds more lines (unless already present) should not be that hard. The second, if I am not mistaken, is identical to the first, except that it requires the user's consent to purchase an additional item? Otherwise it would be the same as the first one. The trick would be that it looks in their sales history to satisfy the behavior. Again a simple cross-reference table stores the rule, a small trigger implements it. The third rule is again another cross-reference. Maybe all three kinds of rules are in the same table with a column to say the rule type. The fourth rule is starting to sound like you're making this up, but I don't know what business this is in and I've seen some strange ones, so I suppose it must be real. This looks superficially like a super-case of rule 3. Adding quantities to the cross reference causes rule 3 to reduce to a case of this rule. For the last one, one way or another you have to query quantities and group by product category. You can do it in a view, in SQL in a trigger, or anywhere else. I am not on the lookout for a complete solution, I simply see allot of business rules like the ones defined above, but never a clean solution to maintaining them (perhaps a DSL or a rule engine is the way to go). Any feedback will be greatly appreciated. -- Yours sincerely Lars Tackmann |
as a possibility.
Some databases I have worked with distinguish between "parts" and
"products". A feature of a "product" is that is can be sold and bought.
Products consist of one or more parts. parts may contain other parts, and
so on. Services, like the right to attend a given offering of a given
course, may be included in "products" by including parts that are
intangible.
The rules you have suggested such as prerequisites and mutual exclusions,
apply to the formation of groups of parts... and not to the formation of
collections of products. In such a framework, the fact that a given person
is buying two pills that should not be taken together is a relationship
between parts, not a relationship between products.
And, in reality, the problem there is not that person X is buying two
pills. It's the likelihood that the same person will swallow both pills.
That would be true even if the person stole the pills, or made one of them
himself.
#73
| |||
| |||
|
|
Lars Tackmann 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 ?. I would rephrase the question to ask if you've come up with a concrete table design that can hold these options. Are they hypothetical, or are these the actual requirements for a real system? The first looks like a cross-reference from products to products, no? So that is easy enough to store. An insert or update trigger that queries the table and adds more lines (unless already present) should not be that hard. The second, if I am not mistaken, is identical to the first, except that it requires the user's consent to purchase an additional item? Otherwise it would be the same as the first one. The trick would be that it looks in their sales history to satisfy the behavior. Again a simple cross-reference table stores the rule, a small trigger implements it. The third rule is again another cross-reference. Maybe all three kinds of rules are in the same table with a column to say the rule type. The fourth rule is starting to sound like you're making this up, but I don't know what business this is in and I've seen some strange ones, so I suppose it must be real. This looks superficially like a super-case of rule 3. Adding quantities to the cross reference causes rule 3 to reduce to a case of this rule. For the last one, one way or another you have to query quantities and group by product category. You can do it in a view, in SQL in a trigger, or anywhere else. I am not on the lookout for a complete solution, I simply see allot of business rules like the ones defined above, but never a clean solution to maintaining them (perhaps a DSL or a rule engine is the way to go). Any feedback will be greatly appreciated. -- Yours sincerely Lars Tackmann |
as a possibility.
Some databases I have worked with distinguish between "parts" and
"products". A feature of a "product" is that is can be sold and bought.
Products consist of one or more parts. parts may contain other parts, and
so on. Services, like the right to attend a given offering of a given
course, may be included in "products" by including parts that are
intangible.
The rules you have suggested such as prerequisites and mutual exclusions,
apply to the formation of groups of parts... and not to the formation of
collections of products. In such a framework, the fact that a given person
is buying two pills that should not be taken together is a relationship
between parts, not a relationship between products.
And, in reality, the problem there is not that person X is buying two
pills. It's the likelihood that the same person will swallow both pills.
That would be true even if the person stole the pills, or made one of them
himself.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.