We are here again after another week and ready for another episode in this series. Today we get to talk about chapter 6 in the book by Alex Kuznetsov (Blog). You can find more on this series by looking here.
Common Problems with Data Integrity
Alex explains to us that SQL server has built-in tools to help maintain the integrity of the data. He quickly lists out three areas that can be useful in maintaining Data Integrity, as well.
- Applications
- Constraints
- Triggers
Application
Data integrity can be enforced from the application. It should be noted that this could be an inefficient method of ensuring the integrity of the data. If you try to do it from the application, be prepared for a little pain.
Constraints
It is well known that using constraints is the most reliable way to enforce data integrity rules.
Using constraints in the database is helpful and quick. If data does not meet the constraint criteria, we can prevent it from being added. There are different kinds of constraints and one should become familiar with the various constraints. In this section, Alex also demonstrates the differences for the three states of constraints. It is important to understand the state of the constraint to ensure the integrity of the data is at the level your expect.
There is a section devoted to UDFs in this chapter as well. The section is within the Constraints section and should be read.
Triggers
The chapter is concluded with the discussion on using Triggers for enforcing data integrity. Triggers are suitable in some areas where a constraint would not be suitable for enforcing data integrity. Triggers do have their own problems that should be considered too though. Some of the problems are with how the trigger was coded and some are inherent with the use of triggers. It is well worth learning about these limitations by reading this section as well. Test the samples provided and implement some of the suggestions in your triggers.
Conclusion
Alex concludes this chapter with the following statement:
Data integrity logic in the application layer is too easily bypassed. The only completelyrobust way to ensure data integrity is to use a trusted constraint. Even then, we need totest our constraints, and make sure that they handle nullable columns properly.
We also have a nice set of reminders of what to include in our assumptions to be tested. The short of it, check your constraints and test as many scenarios as necessary based on your assumptions.
