Re: Why can't SQL SELECT's fire triggers

In article <34msdn$lau_at_stc06.CTD.ORNL.GOV>, ejn_at_ornl.gov (Earl Nall) writes:
|> Oracle allows triggers to be fired when issuing SQL UPDATE, INSERT and
|> DELETE, but not when doing a SELECT. I also see that this is not
|> unique to Oracle as Sybase doesn't allow this.
|>
|> What is the reasoning behind this. It seems logical to me that firing
|> a trigger from a SELECT would be beneficial in many applications (e.g.
|> access control).

Before declarative constraints became the standard mechanism for RDBMS' to enforce referential integrity, Sybase made the design decision (I guess) to do it via triggers. It proved to be quite handy, so other vendors started including it in their products as well.

Triggers are primarily a mechanism to enforce complex business rules and ensure the integrity of data when it is modified in any way (INSERT, UPDATE and/or DELETE). SELECTs do not affect the data, therefore, do not require any action. We have privileges to manage access control. I admit that there are times when SELECT triggers might be handy, but this is the way it works.

                                Teresa Larson

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Teresa A. Larson - Hughes STX Corporation                            |
| NASA/GSFC Code 933.0                        voice:  (301) 286-7867   |
| Greenbelt, Maryland  20771                  fax:    (301) 286-1777   |
| Teresa.Larson_at_gsfc.nasa.gov                                          |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
			Standard disclaimer ...