Re: Lots of code. How many tables.

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. Complex constraints or constraints which have a time component (alter with time) are often better implemented by the application. For example a code which is valid and legal but can not be used for new entries. (Except when entered under special circumstances and antidated).

Implementing a constraint as a trigger is not favored in our organisation, because it's has to be implemented in different databases and using business logic is more suetable, because of the 'rules' of the constraint. (Offcourse when business logic has to be implemented more than once the same argument can be used the other way round.).

At the moment I tend to go with your arguments for implementing each codetype with it's own table. Because this allows for referential constraints
on each code. And implementing a table is a fairly simple action in contrast to implementing a constraint in business rules. The business implemented constraints are still possible for the more demanding constraints.

Still looking for a description on the web of the 'Generic Model'.

ben brugman Received on Thu Feb 12 2004 - 10:23:33 CET