Re^7: OO concepts and relational databases

[adrianh]

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.