Integrity Constraints

Integrity Constraints don't require procedural coding, thus they are easier
to implement syntactically. Procedures take more server memory and perhaps
you'll have several more "source" code files to manage for your project.

In the flip side, in our "real world" I find that most of our Ingres
developers design applications that are "most of the time" too complex to be
implemented in integrity constraints and they virutally always setup the
application's "rules" as triggers/procedures right from the start.

HTH

"Clovis V. Protti" and/or "Claudia S. Lopez"  wrote in
article <33937541.58AC@eu.ansp.br>...
> Please,
> 
> Anyone can tell me your experience in use of Integrity Constraints; what
> would you rather to use, Integrity Constraints or Rules ??
> 
> Thank you for any help you can give to me.
> 
> Clovis
> 




For CHECK CONSTRAINTS I would recommend use of constraint rather than 
rule.

For UNIQUE, PRIMARY KEY and REFERENTIAL CONSTRAINTS you should be aware 
that these are implemented in OI by use of internal rules and database 
procedures and that each constraint creates a different secondary index 
on your database table.

Implement many constraints and you will have many secondary indexes - 
with possible impact on locking, update performance and query 
optimisation times.

Often, depending on access paths, it may be better to create a unique 
primary index on your primary key (eg. modify table to btree unique), 
rather than to use a primary key constraint.

John
Ingres Q & A
To William's Home Page
Email William