 | |
#1
 
| |||
| |||
|
Business Rules -
03-27-2008
, 07:22 AM
#2
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#3
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#4
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#5
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#6
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#7
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#8
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#9
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
#10
| |||
| |||
|
|
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 ?. |
E1 <= E2
where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.
In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).
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.
 |
« 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.