Re: Trigger programme without a trigger.

rob@xxxxxxxxx wrote:

Joe,

I was wondering when you were going to pipe up on this one. I knew you were no big fan of constraints and formerly worked for a company that was known to never put a primary key on a file, and, not even make the "primary" key UNIQUE in any logical associated with the physical.

You like to bring up the past, dontcha, Rob? The designs at SSA in the 1980s have little to do with my positions today. So the next time you wanna question my position on things, feel free to leave off any references to a company I worked at 20 years ago.

With the logic being that all updates to the files were supposed to go through the standard 5250 data entry programs. Although the labor associated with making something to emulate punching the keystrokes during a file conversion or a merge was rather astronomical.

Stuff like this. It's a complete waste of bandwidth. Even way back then, at SSA we built load programs. We built file conversions. We designed thick client applications that updated the data from graphical PC applications. In any case, I,. Joe Pluta, never forced you, Rob Berendt, to use a keystroke emulator or anything like it. So feel free to drop this line of discussion. Ancient history is fun and all, but I'm talking about today's architecture.

Now, I do realize that the I/O modules often touted by those who:
- have the ability to write the I/O modules
- are never restricted themselves to only using the I/O modules and forbidden to even know the layout of the files
are quite different than being restricted to 5250 data entry programs.

Is there a question here? Or were you content to just bash SSA and bash me by association?

I'm serious. Is there anything constructive in this entire post, or did you just feel like taking a 2x4 to my head today? I can understand the latter; it wouldn't be the first time. But I fail to find a point in all of this.

My position is simple: I/O modules are an alternative to triggers, and the decision should be a business decision, not one based on an inability to enforce your own security. I don't say you're wrong to use triggers, and I'm not questioning the qualifications of someone who likes them. I just ask that you use them for the right reasons.

On the other hand, I *absolutely* believe that if you are in charge of security and you also can't count on your own security, then you ought to find a new career. Using "accidental" security breaches as a design decision point is indefensible.

Joe