I assume you are talking about maintaining Referential Integrity between Parent-Child tables in the db. There are three options:
1 ANSI standard declarations (CONSTRAINT ... FOREIGN KEY)
Least performance cost and the most secure
More performance cost, now deprecated (since (1) is available), administration problems.
3 Application Code (SQL)
Most performance cost, least reliable, administration problems.
If you are using (3), then at least you should be doing it in stored procs (static SQL) and never in dynamic SQL (which means you are compiling every time and is an unacceptable performance cost).
In any case, an "application" should consist of client code plus a set of procs (business transactions) to update the db, which should verify the validity of the business transaction before attempting it. This should include Referential Integrity verification: in the case of (3) it is crucial; in the case of (1) it is good standards for high performance transaction systems (never attempt something that will fail; find the failure early rather than late in the code; report specific errors back to caller).
Senior Sybase DBA/Information Architect derekATsoftwaregemsDOTcomDOTau
Anything worth doing is worth doing Right The First Time
Spend your money on standards-compliant development or spend 10 times more fixing it