|Perl: the Markov chain saw|
Re^4: OO concepts and relational databasesby dragonchild (Archbishop)
|on Aug 03, 2004 at 02:39 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. That has nothing to do with data integrity and everything to do with business logic. (You even named your trigger accordingly.)
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. Credits, debits, and balances are a business rule. Data integrity would require that every credit and every debit have a valid FK to the current_account table. Whether or not they balance is an application issue.
This is actually a pet peeve of mine. Putting business rules into the datastore limits your options. You end up not being able to do the following:
That last item may be a bit confusing, so I'll explain the reasoning behind it. Most databases begin life supporting one application, so there's a bit of myopia involved in the design, especially of the schema and supporting triggers / stored procedures. Some places put a lot of the business rules into the database.
So, let's say you do that and your database has been very successful. Now, your manager / VP / whomever wants you to add another application. Say, a reporting application for the clients, over the Web. Not a problem. But, now they want you to add the capability to have the clients update the data. Oops!
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.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested