There is one men that have an opinion that business rules might be at only one place in the application, so for our team and project it meens that in our relational database there is no foreign keys and constraints. Business rules in this project are placed into entities (DAO). Please give real hard argument to change his mind about this..
Asked
Active
Viewed 82 times
-1
-
2This opinion is patent stupidity that should be held up to public ridicule. Every choice is not a business rule. Is that person a Rete rules engine salesman or something? – duffymo Mar 16 '12 at 09:33
-
You don't need to change his mind. You just need to fire him. – Moo-Juice Mar 16 '12 at 09:34
-
I am just developer, so I can't fire this guy) He is one of lead person of this project. – overwriter Mar 16 '12 at 09:39
-
2Dispensing with referential integrity in databases is not the best solution, especially if that database is transactional and shared. Every application that uses it will have to duplicate what referential integrity can provide. That doesn't make sense. Like all dogma, this is a poor substitute for real knowledge and honest thinking. – duffymo Mar 16 '12 at 09:44
-
@duffymo, thanks from your comment I get one nice argument "May occur some problem with transactions, even more not 'may' but 'must'." – overwriter Mar 16 '12 at 10:09
1 Answers
2
Foreign keys are not business rules.
They are used to to make sure that the database has correct relations between its tables. No constraints just means that the database can contain junk data (which probably will grow over time).
A programmer can not guarantee that the code works bug free, hence there is nothing to make sure that all data is valid.
A single table do not represent a business/domain model. One or more tables do. So it's not a 1-1 relationship between a busniess/domain model and the database tables. And it's therefore that the business rules can not guarantee that the db contains valid data.

jgauffin
- 99,844
- 45
- 235
- 372
-
I understand that, my opinion is that is wrong to ignore posibility to set foreign keys, constraints to have consistent database. – overwriter Mar 16 '12 at 12:12
-
1