quote:

---

Your trust of client-side applications depends on who controls the building and testing of those applications. If you trust those people then you will not need to use constraints. If you don't trust them then using constraints will give you the assurance you need.

---

The question should not be "do I trust those people or do I not". It sounds kind of personal, offensive and... not technical. Instead we may want to think "how do I protect data integrity of my database now and in the future". What if those trustworthy people quit and new ones arrive? What if a new application starts feeding the database? What if "bad data" is put into the database by a mistake? Of course, some trustworthy people never make mistakes but all those are already hired by.. the marsians I guess.

Examles given in the article are not very good. I would not put such a constraint on a telephone column. It does not break any integrity if someone put a "strange" value in a telephone column. The given LIKE check is very expensive. Checking birthdat with LIKE is also not needed. If you really cautious, use >= and <= operations but this one could be left to the business rules implemented somewhere else.

It seems the author of the article took the worst (slowest) types of constraints. There are better examples. In addition, the article does not even mention the word PERFORMANCE.

Edited by - mromm on 06/09/2003 09:49:43 AM