Why do we do double work?

[Sender]

When we develop a package using front end like Visual Basic etc. then we can
write code to validate what kind of data the user can enter, save, update or
delete. For example, if we want the Name should not be greater than 20
characters, we can write code for this validation. If we want that EmpID
should be unique, we can write code for this. If we want that Salary should
always be a positive number. I mean we can write code to completely manage
how the data should be delete/saved/updated in our database.

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?

[Jeff Clausius]

sender:

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:

[Tibor Karaszi]

I think this is also a matter of finding the client side bugs ASAP. An example: I had a data
model with scheduling info. We had 0, 10, 20, 30, 40 and 50 to specify which minute to execute
(there's another value with offset, but that is irrelevant for this discussion). The server was
written according to this.
When I wrote the client, I by mistake wrote code to create entries for 0, 1, 2, 3, 4 and 5. At
first test of the client app, the constraint told me about this. Without constraint, I would
have saved the data, and wonder why the server didn't execute the task as scheduled...

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...