Re: Arbitrary Constraints

Laconic2 wrote:
> There is a legitimate design question around where you want to
enforce
> business rules.
> And it's possible that the right answer might be "in more than one
place".
>
> I can easily see situations where the UI enforces a "field not blank"
rule
> on the user, and the database enforces a
> "column not null" rule on the incoming data, even though this might
be
> seen as redundant.

Agreed - that is exactly the sort of constraint I would expect to see implemented in both places:
1) By the DBMS - because the DBMS wants to ensure the integrity of the data regardless of source
2) In the UI - redundantly, because the DBMS would reject anyway; but it has the advantages that (a) the user gets informed immediately, on exit from the field, rather than only when the data has been submitted, and (b) we avoid the expense of a wasted "round trip" to the DBMS.

The important consideration that is so often overlooked by people with a "developer" mindset and not a "database" mindset is that applications come and go, come and go, but the data is there "forever". Right now, everyone is re-building their old apps using Java; in 5 years time it may be C#.NET or some as yet unknown super-language. Also, even while the current UI exists, there is often a push for new alternatives: web-based applications, mobile phone-based applications maybe; a batch process that receives XML by email and populates the database; whatever. The more robustly constraints are enforced by the DBMS, the easier and less dangerous it is to allow these UI upgrades and alternatives. Received on Wed Oct 27 2004 - 15:10:37 CEST