Re: Lots of code. How many tables.

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<jNadnXJaN6gLK7bdRVn_iw_at_golden.net>...
> "ben brugman" <ben_at_niethier.nl> wrote in message
> news:402b4617$0$1407$4d4ebb8e_at_read.news.nl.uu.net...
> > Thanks Tony and Anton,
> >
> > Thanks for your participation and pointing out the 'extra'
> > difficulties in implementing 'constraints' in more generic models.
> > But I am aware of that. And I agree totaly with that if a constraint
> > can be implemented as a referential constraint in a database
> > this is the first choice. But it is not the only choice and not
> > in all cases the best choice.
> >
> > Implementing the constraints in business logic (or in the application)
> > is valid way to implement constraints.
>
> Only as a last resort when one has no other option. Otherwise, it only makes
> sense to manage data integrity with a data management system.

Well put! Apart from being blinkered ("the only way data gets in is via THIS application code"), enforcing data constraints in the application is far more difficult than most people who try to do it realise. For a start, EVERY bit of application code that inserts a row into a table that has an application-enforced "foreign key" to a generic code table (GCT) better LOCK the parent row in the GCT to prevent another user deleting it... Received on Fri Feb 13 2004 - 12:29:50 CET