Re: Check constraint violated

Ed Prochak wrote:

> Well, your requirement doen't sound like a check constraint, but a higher
> level business rule. You need to enforce it in the application layer.
> Constraints cannot solve ALL these problems, and you don't want to be
> changing the DB each time a rule like this changes.

*NO!!!*

What is easier?

Changing the db layer? I.e. changing a PL/SQL stored proc, or a constraint or creating a view?

Or change the front-end client? Then change the Corba C IDL on the client? Then change the Corba code?

Then pray that it works and that you have not screwed up anything in any of the layers?

Okay, let's make it simpler. Throw away the middle tier and deal with the client only.

New business rule. Column END_DATE in table FOO must be larger than the 1st of Jan 2003. Update the client. Then distribute the update to 10,000 users.

Only.. what happens to the old users who due to some problem do not get the update? And keep on running the old software with the old business rule? App versioning you say? Great. Then you will have 5,000 users calling support complaining that they can not do their work as their app version is no longer valid and they have not yet received the new update (as the corporate LAN is hammered by app distribution).

Then you have other departments jumping up and down as the LAN is so bottlenecked, they can not do their work either.

The client side should deal with data/information presentation. That is what is is there for. INTERACTION between the database and the user. Not for enforcing data integrity. And especially not for enforcing business rules.

Enforcing business rules in client software IS *STUPID*. Period.

I sometimes wonder if there are only a few of us here that actually work in the friggen REAL WORLD.

Or else you guys must be smoking something. If so.. please pass some along my way.

--
Billy