No rule is not enough-SQL server constraints

The database function is to manage a large amount of data. When the number of things to be managed is huge, certain restrictions or rules are required. For example, transportation requires traffic rules, Civil Aviation requires air traffic control, and the State requires laws. If these restrictions are removed, the world will be in chaos. In databases, this restriction is called a "constraint", which guarantees data integrity. After the constraints are encapsulated, the rule becomes a rule. The rule is an object. It maintains data integrity through binding and simplifiesCodeReuse code.

There are five constraints:

1. Primary Key constraints

A primary key constraint is a combination of one or more columns in a table that uniquely identifies each record. A column defined as a primary key cannot have null values, the data type cannot be text or image. Our student ID can be defined as the primary key. Note that each table can only have one primary key, but it is not mandatory. Because primary keys are unique (resources are scarce), the following principles must be observed when defining primary keys: 1. Primary keys should be meaningless to users. 2. Primary keys should be a single column. 3. Primary keys should never be updated. 4. Primary keys do not apply to dynamically changing data. 5. Primary keys should be generated by computers. Of course, it is not easy to satisfy these conditions. Therefore, when selecting a primary key, you must pay attention to the balance of several principles.

2. Foreign key constraints

A foreign key constraint defines the relationship between tables. It is relative to a foreign key. When a record identified by a primary key is updated, the record with the same primary key in the column defined as a foreign key is automatically updated to ensure data integrity between tables. When a table is defined as a foreign key constraint, only records existing in the primary key table can be inserted. That is, the "foreign key table" must be included in the "primary key table". Otherwise, it will be considered invalid.

3. uniqueness constraints

The Uniqueness constraint is used to ensure that the column does not have the same value. If a student information table is defined as a uniqueness constraint for student IDs, duplicate student IDs are not allowed. If the student ID has been defined as a primary key, the uniqueness constraint cannot be defined.

4. Verification Constraints

Verification constraints are used to ensure that the entered values meet certain ranges or conditions. Otherwise, it cannot be updated. If the employee's salary in the payroll table is required to be between 3000 and 4000, records cannot be updated once the input value is not in this range. This avoids the occurrence of incorrect data. If only 3000 of the monthly salary is sent but 30000, the boss will be crazy. One sentence: only data that meets the verification constraints can be accepted.

5. Default Value Constraints

This is to set a default value for a field without input values. This is not much to say.

Constraints can be managed through the visual manager, or through the T-SQL statement, the length of this talk is limited, forget it.

Rules. In my opinion, rules are encapsulated constraints. Rules are bound to fields to implement functions. Therefore, rules can be reused after they are created. You can bind rules to anyone who needs them. Use the system stored procedure SP-bindrule for binding.

Ah, it's all nonsense. It's useless. You can't write it anymore !!!