You've heard me talk about them, but now it's time to look at them seriously — it's time to deal with constraints. We've talked a couple of times already about what constraints are, but let's review in case you decided to skip straight to this chapter.
A constraint is a restriction. Placed at either column or table level, a constraint ensures that your data meets certain data integrity rules.
This goes back to the notion that I talked about back in Chapters 1 and 2, that ensuring data integrity is not the responsibility of the programs that use your database, but rather the responsibility of the database itself. If you think about it, this is really cool. Data is inserted, updated, and deleted from the database by many sources. Even in stand-alone applications (situations where only one program accesses the database), the same table may be accessed from many different places in the program. It doesn't stop there though. Your database administrator (that might mean you if you're a dual-role kind of person) may be altering data occasionally to deal with problems that arise. In more complex scenarios, you can actually run into situations where literally hundreds of different access paths exist for altering just one piece of data, let alone your entire database.
Moving the responsibility for data integrity into the database itself has been revolutionary to database management. There are still many different things that can go wrong when you are attempting to ...