Re: Trigger programme without a trigger.

rob@xxxxxxxxx wrote:

And here's my last rebuttal to you, Rob.

However, if one is ultra serious about I/O modules then why would one use "external" definitions on their files and not the structures that S/36 (and before) people had to use? After all, if only one I/O module has access to it, then using no external definitions is further assistance to "security by obscurity" and further encouragement to use the I/O module.

See, this is my problem. I don't care whether after a reasoned design process you decide to use triggers and constraints and whatever. But the fact that I don't like them shouldn't be a religious war. And then extrapolating it this way does nothing to help. For example, using an HSA profile doesn't somehow imply internal definitions. There are plenty of good reasons to use external definitions: I may have multiple programs that access the data, they're just all secured. It's just the outside world that can't access the data. (Heck, even if I don't use SQL I want to define my files with DDL, because they're faster to read that way.)

You've stripped off the use of constraints, referential integrity, journals, triggers, (and a lot of people - real date fields) why not strip off external definitions also?

I haven't stripped off anything. I've only said that triggers are not inherently more secure than HSA profiles. If you want to argue the architecture of triggers, and why you think they're a better solution for a specific application design point, that's fine. I can certainly see situations when they can help. But securing the data isn't one of them. And once you get past that particular red herring, it's easier to see situations where triggers are *not* the best solution.

Some may argue that going back to no external definitions will send them off to ga-ga land, especially if they just "nativized" their last S/36 customer. My argument is leaving their files without constraints, referential integrity, journals, triggers and real date fields sends me off to ga-ga land.

And as long as you identify it as a personal decision based on your expertise and experience, and don't try to tell other programmers that they're somehow less advanced because they didn't come to the same conclusion, then it's all good. At that point, it becomes a business decision again.

Joe