Υποστηρίζονται η απενεργοποίηση και η ενεργοποίηση των περιορισμών ξένου κλειδιού στον SQL Server; Ή η μόνη μου επιλογή είναι να αποσύρω και στη συνέχεια να δημιουργήσω τους περιορισμούς;
Αν θέλετε να απενεργοποιήσετε όλους τους περιορισμούς στη βάση δεδομένων, απλά εκτελέστε αυτόν τον κώδικα:
-- disable all constraints
EXEC sp_MSforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT all"
Για να τους ενεργοποιήσετε ξανά, εκτελέστε: (η εκτύπωση είναι προαιρετική φυσικά και απλώς παραθέτει τους πίνακες)
-- enable all constraints
exec sp_MSforeachtable @command1="print '?'", @command2="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"
Το βρίσκω χρήσιμο όταν συμπληρώνω δεδομένα από μια βάση δεδομένων σε μια άλλη. Είναι πολύ καλύτερη προσέγγιση από την κατάργηση των περιορισμών. Όπως αναφέρατε είναι βολικό όταν ρίχνετε όλα τα δεδομένα στη βάση δεδομένων και τα ξαναγεμίζετε (π.χ. σε δοκιμαστικό περιβάλλον).
Εάν διαγράφετε όλα τα δεδομένα, ίσως βρείτε χρήσιμη την αυτή τη λύση.
Επίσης, μερικές φορές είναι βολικό να απενεργοποιήσετε και όλα τα triggers, μπορείτε να δείτε την πλήρη λύση εδώ.
http://www.sqljunkies.com/WebLog/roman/archive/2005/01/30/7037.aspx
-- Disable all table constraints
ALTER TABLE MyTable NOCHECK CONSTRAINT ALL
-- Enable all table constraints
ALTER TABLE MyTable WITH CHECK CHECK CONSTRAINT ALL
-- Disable single constraint
ALTER TABLE MyTable NOCHECK CONSTRAINT MyConstraint
-- Enable single constraint
ALTER TABLE MyTable WITH CHECK CHECK CONSTRAINT MyConstraint
Το πρότυπο SQL-92 επιτρέπει να δηλώνεται ένα constaint ως DEFERRABLE, ώστε να μπορεί να αναβληθεί (σιωπηρά ή ρητά) εντός του πεδίου εφαρμογής μιας συναλλαγής. Δυστυχώς, ο SQL Server εξακολουθεί να στερείται αυτής της λειτουργικότητας SQL-92.
Για μένα, η αλλαγή ενός περιορισμού σε NOCHECK μοιάζει με την αλλαγή της δομής της βάσης δεδομένων εν κινήσει - η απόρριψη περιορισμών σίγουρα είναι - και είναι κάτι που πρέπει να αποφεύγεται (π.χ. οι χρήστες απαιτούν αυξημένα προνόμια).