Managing Constraints
Managing
constraints consists of gathering information about constraints,
disabling and re-enabling constraints, and dropping constraints. These
actions are discussed in the following sections.
Gathering Constraint Information
You can obtain information about constraints by using the visual tools, system stored procedures, and information_schema
views. The visual tools (including the Object Explorer, Table Designer,
and database diagrams) were introduced in the previous section. These
tools offer a simple, user-friendly means for obtaining information
related to constraints. These tools allow you to view a table’s
constraints and display the relative information.
The sp_help and sp_helpconstraint
system stored procedures are another good source of information about
constraints. Like the visual tools, these procedures allow you to gather
constraint information about a specific table. The sp_helpconstraint procedure provides the most concise information related to constraints. Figure 7 shows the sp_helpconstraint output for the Sales.Customer
table. You need to make sure to enclose the table name in brackets, as
shown here, when the schema name is included. The output from sp_helpconstraint includes all the constraints for the table, and it supplies a list of tables that have foreign key references to the table.
Catalog views offer a
flexible alternative for returning information about constraints.These catalog views allow you to obtain constraint
information for more than one table at a time. They are very flexible
and allow you to customize the type of data you want to return simply by
adjusting the selection criterion.
Listing 4 shows a sample SELECT statement for each of the catalog views related to constraints and the resulting output. The SELECT statements in this example have a WHERE clause in them that limits the results to the SalesTax table, but you can remove this clause to retrieve constraints for all the tables.
Listing 4. Using Catalog Views to Display Constraint Information
select LEFT(name,30) NAME, type from sys.key_constraints
where object_name(parent_object_id) = 'SalesTaxRate'
order by 1
select LEFT(name,30) NAME, type from sys.check_constraints
where object_name(parent_object_id) = 'SalesTaxRate'
order by 1
select LEFT(name,30) NAME, type from sys.default_constraints
where object_name(parent_object_id) = 'SalesTaxRate'
order by 1
/* Results of the previous SELECT statements
NAME type
------------------------------ ----
PK_SalesTaxRate_SalesTaxRateID PK
(1 row(s) affected)
NAME type
------------------------------ ----
CK_SalesTaxRate_TaxType C
(1 row(s) affected)
NAME type
------------------------------ ----
DF_SalesTaxRate_ModifiedDate D
DF_SalesTaxRate_rowguid D
DF_SalesTaxRate_TaxRate D
(3 row(s) affected)
*/
|
Dropping Constraints
You
can drop constraints by using the visual tools or by using T-SQL. You
can right-click a constraint in the Object Explorer and select the
Delete option to drop that constraint. The Object Explorer also offers a
script option that generates the T-SQL statements used to drop the
constraint. The ALTER TABLE command is the T-SQL command you use to make the change. For example, to drop the CK_Employee_Gender constraint on the Employee table, you can use the following command:
ALTER TABLE [HumanResources].[Employee]
DROP CONSTRAINT [CK_Employee_Gender]
You should use caution when dropping constraints because some constraints affect other tables. For example, if you drop the PRIMARY KEY constraint on a table and that table is referenced by foreign keys, the drop statement fails.
Disabling Constraints
You can disable CHECK and FOREIGN KEY constraints by using the NOCHECK
clause. This capability allows you to stop the constraints from being
checked without removing the constraints from your database. The
following ALTER TABLE command allows you to disable the FK_Customer_SalesTerritory_TerritoryID foreign key constraint on the Customer table:
ALTER TABLE Sales.Customer
NOCHECK CONSTRAINT FK_Customer_SalesTerritory_TerritoryID
When the constraint
is disabled, it no longer performs validation. You should disable
constraints with caution because the integrity of your data can be
compromised. In the previous example, disabling the FOREIGN KEY constraint would allow an invalid TerritoryID to be inserted in the Customer table.
Why would you disable
constraints? One possible reason would be to disable the constraints
during large data loads. The execution of constraints can slow the load
process. To facilitate the fastest load speed, you can disable
constraints and then re-enable them when the data load is complete. To
re-enable a constraint, you use the CHECK keyword in the ALTER TABLE statement. The following example re-enables the FOREIGN KEY constraint for the Customer table:
ALTER TABLE Sales.Customer
CHECK CONSTRAINT FK_Customer_SalesTerritory_TerritoryID
Keep
in mind that enabling a constraint does not necessarily mean the
underlying data is being validated against the constraint. In fact, the
default behavior when enabling a constraint in SQL Server 2008 is not to
check the data against the constraint when a constraint in enabled. The
default behavior when a constraint is added is to validate the data.
You can force the data in the table to be validated using the WITH CHECK option. The following WITH CHECK option could be used to force the validation of the underlying data when a constraint is enabled:
ALTER TABLE Sales.Customer
WITH CHECK CHECK CONSTRAINT FK_Customer_SalesTerritory_TerritoryID