|P is for Practical|
Re^5: OO concepts and relational databasesby adrianh (Chancellor)
|on Aug 03, 2004 at 05:00 UTC||Need Help??|
Triggers do not have to affect the table that they trigger upon. For example, we have a trigger that will add rows to other tables when the given table is inserted into.
True, but I'm afraid I don't understand the point that you're trying to make.
In my opinion, you are confusing business rules and data integrity. Data integrity is a set of rules about the form of the data, based on how the data moves. Business rules have to do with things like you discuss.
I've failing to see the clear distinction that you appear to be drawing between business rules and data integrity. I've certainly been using the latter term in the sort of contexts I discussed previously for over ten years with nobody apparently getting confused ;-)
This is actually a pet peeve of mine. Putting business rules into the datastore limits your options.
I agree. Putting business logic in the database layer is often a mistake. The most common problem I see is splitting the same 'layer' of business logic between the database and non-database code, which gets you the worse of both worlds.
That said, you fail to list the advantages. Putting at least the basic business rules in the database allow you to present the relation model to the application and be certain that a poorly coded application isn't going to foul up your data. Database-side logic can also be a lot faster since you don't have to throw stuff over the wire.
While I tend to keep my business logic out of the database (because most of the projects I work on aren't of a sufficient scale to make it useful) it comes down to the project and the team. There are no hard and fast rules either way.
You now need to scour every single bit of code within the database to make sure that seemingly simple data changes that the web application wants to make won't adversely affect your database because every time you made that data change within the internal app, you always wanted to do XYZ as well. It's much simpler to have a webservices-type design with N tiers. That way, each tier does one thing, one thing only, and does that one thing well.
I don't understand the point you are making here.