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.

The point with the trigger is that the trigger isn't a behavior of the table itself. You cannot ask the table to do something, simply because it has a trigger on it. To have the trigger code execute, you must perform an action upon the table. The database engine, upon seeing that action performed upon the table, executes the code in the trigger. It's not a behavior of the table, but a behavior of the engine.

Another way to put it would be this - if it was a behavior of the table, you would be able to move the table from one schema to another and the behavior would move with it. But, you can't do that in any RDBMS I've ever worked with.

Another way to think about it would be this - if it was an behavior analogous to the OO sense of the word, it would only be allowed to affect its state and request that the objects it contained affect their state. But, most non-trivial triggers I've seen are meant to affect the state of other tables, given the new values in this table.

As for stored procedures ... I can see advantages to putting code in stored procedures ...... if you're remediating an existing application and the current developers are dunces. Otherwise, why would you put the code in the database as opposed to putting in a middle-tier? You could even restrict access to the database to that middle-tier, forcing all access to be moderated the same way it would be moderated through the stored procedures. But, instead of having to program in two languages (one of which is going to be substandard), you would be able to keep all your code in one language (Perl, for example) and would not be tied to one datastore vendor.

------
We are the carpenters and bricklayers of the Information Age.

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

The point with the trigger is that the trigger isn't a behavior of the table itself. You cannot ask the table to do something, simply because it has a trigger on it. To have the trigger code execute, you must perform an action upon the table

I'm sorry but I'm just not understanding the distinction that you're trying to draw here. Yes to get a trigger to execute you have to perform an action upon the table - this seems a fairly clear association between trigger and table to me.

Maybe we're just in violent agreement :-)

Another way to put it would be this - if it was a behavior of the table, you would be able to move the table from one schema to another and the behavior would move with it. But, you can't do that in any RDBMS I've ever worked with.

Dump. Load. What am I missing?

if it was an behavior analogous to the OO sense of the word, it would only be allowed to affect its state and request that the objects it contained affect their state. But, most non-trivial triggers I've seen are meant to affect the state of other tables, given the new values in this table

I'm wasn't my intent to argue that triggers and stored procedures are directly analogous to OO methods. My bone of contention was when you said:

However, stored procedures, while within the database application, have very little to do with the core function of a database - data storage and retrieval. At best, they are syntactic sugar that can help maintain data integrity. But, that is a far cry from saying that databases have behaviors.

Since I don't think "syntactic sugar that can help maintain data integrity" is an accurate description of the way that triggers and stored procedures are used.

Otherwise, why would you put the code in the database as opposed to putting in a middle-tier?

Off the top of my head:

• Efficiency (no round trip to the server)
• Wanting to keep direct access to the relational model (if you hide everything behind a Perl/Java/whatever layer you lose the advantages of direct access to the relational DB)
• Portability (if you're developing applications that use the database in several languages having the business logic sitting in the database might be the simplest solution to providing it to all the different platforms)
• Security (since the database is often centralised and highly controlled it can be much easier to prevent bad clients fouling up the data)
• Directness (often the restrictions you want to talk about are best expressed in the relational model, and the fiddling with it is most directly done at the table level)
• Team experience (if the people who know the business logic best are the database folk their probably going to be most effective using the tools they know well)

But, instead of having to program in two languages (one of which is going to be substandard), you would be able to keep all your code in one language (Perl, for example) and would not be tied to one datastore vendor.

The language needn't be substandard (e.g. PostgreSQL allow database-side development in many languages including Python and Perl). Also, for many organisations being tied to one datastore vendor is no more of an issue in application development than being tied to one language vendor.