Though the line is drawn in
different places for different applications, the basic principle is this: the database
should not enforce business logic, but it should enforce consistency and integrity.
Regardless of differences of opinion on check constraints, one type of constraint is
non-negotiable: foreign-key constraints. If a foreign-key relationship is required, an
unassociated record is semantically meaningless and must not be allowed to happen.
It only makes practical sense to formalize that association.
The only truly robust way to ensure that a database maintains integrity over years as it
accumulates data (as databases tend to do) is to declare appropriate constraints on the
data. Unless you can say for certain that every application or person accessing the database
will do so through the domain model (going through all associated validations)
every time, the only sensible option is to treat the database as an integration database.
There is a bonus to providing constraints: typically, the more constraints provided
on a database, the better job the query optimizer can do at creating a query plan.
A common complaint about database constraints is that they require you to specify
semantic information in two places: your database and your application code (you
usually want to trap invalid data in your application??™s validations before attempting
to insert it into your database, even if the database would catch the error anyway).
Pages:
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176