Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

check constraint opinion? Expand / Collapse
Author
Message
Posted Tuesday, September 25, 2012 10:05 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 8, 2014 5:29 PM
Points: 121, Visits: 300
What's your opinion on check constraints in SS?

Check constraints seem good for enforcing constraints at the table level. Putting validation at other levels does not prevent a user from directly entering invalid data in the database.

However, can check constraints potentially slow the database down or create other issues?
Post #1364159
Posted Tuesday, September 25, 2012 12:10 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 11:55 AM
Points: 13,110, Visits: 11,941
sqlguy-736318 (9/25/2012)
What's your opinion on check constraints in SS?

Check constraints seem good for enforcing constraints at the table level. Putting validation at other levels does not prevent a user from directly entering invalid data in the database.

However, can check constraints potentially slow the database down or create other issues?


I am not 100% sure what you are looking for as an answer but...yes check constraints can potentially slow down the database. In fact, they will slow it down. The more important question is how much. Check constraints are usually really really fast to the point that the performance difference is unnoticeable and even difficult to measure. As a DBA it is your job to ensure the data. If that means that only values in a certain range or something like that then you should use check constraints. This is one of the ways as a DBA you have of ensuring that garbage data does not get in the system. I would never trust the validation outside of the database to be consistent. You just need to be sure that whatever constraint you establish is in line with the data requirements.


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1364219
Posted Wednesday, September 26, 2012 2:46 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Saturday, July 26, 2014 8:57 AM
Points: 7,081, Visits: 12,575
An alternative to CHECK constraints are Foreign Keys referencing lookup tables. These are useful when you need to validate that a value in a column is within a set and that set may need to be changed periodically. For example if your company ships to customers in the USA and Canada you could have a CHECK constraint on the Country column in your CustomerAddress table that made sure that was the case, however if you think you may someday ship to Mexico you may instead want to create a table named Country, add rows for USA and Canada and reference it using a Foreign Key. The, when you start shipping to Mexico you simply add a row to the Country table and from that opint forward you can add rows to CustomerAddress using the new country code.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1364939
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse