Re^6: OO concepts and relational databases

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

Comment on Re^6: OO concepts and relational databases

Replies are listed 'Best First'.
Re^7: OO concepts and relational databases by adrianh (Chancellor) on Aug 03, 2004 at 14:13 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^7: OO concepts and relational databases
by adrianh (Chancellor) on Aug 03, 2004 at 14:13 UTC

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.

[reply]