Re: "All triggers are evil",..., really?

That approach may work, but for all intents and purposes, I'm strictly a one-man shop. Using instead_of_triggers against views was a quick and (almost) simple solution for me.

I wanted to prohibit anybody from accessing the base tables directly, and only allow access against views. Restricting everybody this way, with the triggers, pretty much allows me to know that no matter what home-built application is used to access or modify data in my database (it is a scientific database), the proper logic to handle the underlying base tables is in place. I can control the database, but once the ODBC connection is "out-of-the-bag", I have absolutely no control over what somebody else designs to access the data.

Most places don't have to worry about this, but in my environment, it's a reality I have to live with. As my tables change (new tables, new fields, field re-definitions, etc.), constantly updating an API and trying to guarantee that any and all programs only access the tables/views through it seemed like a lot more work for me. Maybe if I had another person or two to help me out, then it very well could be a different story though.

Thanks for the suggestion though. One of these days if they ever give me any backup, that would be area worth exploring further.

-- 
-- Bill Ferguson


On Thu, Aug 21, 2008 at 6:45 AM, Stephens, Chris
<chris_stephens_at_admworld.com> wrote:


> Why not define an adequate api and only allow modifications to the

> underlying tables through that api?  Read access could go directly

> against the tables.

>

--
http://www.freelists.org/webpage/oracle-l