Now my questions is then why do we have to the double work. Then where is
the need to define the constraints (column level or table level) in the
database tables if everything we can do in the Front-end development
language. Also, even we if we define the constraints in the database tables
still to check whether there is any violation of those constraints we have
do write code in front-end application at least to trap the error to know
constraint failed?
as a general rule, the closer the restrictions (checks, sizes, etc) are
to the data, the cleaner your data will remain over time.
so, after your basic program evolves into your visual basic program
evolves into your visual basic.net program evolves into the next
language program, the data usually remains constant. imagine the amount
of bugs possibly introduced by re-writing the same logic over and over
again.
however, if you put as much of the checking that is possible in at that
database level, those checks remain constant (and virtually bug free)
through all iterations of changes to the front end database application.
jeff
sourcegear corporation
ps. i didn't even open the can of worms of other front end applications
using the database. whose to say they have the same restrictions built
in as your front end application.
"Sender" <us...@domain.com> wrote in
news:#myoZGWR...@TK2MSFTNGP11.phx.gbl:
Nothing new here, just wanted to push the point that constraints can be a great timesaver by
finding incorrect code immediately!
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Jeff Clausius" <je...@sourcegear.nospam.com> wrote in message
news:Xns93B464DD3EABCj...@207.46.248.16...