How important are constraints like NOT NULL and FOREIGN KEY if I'll always control my database input with PHP?

Question

I am trying to create a column in a table that\'s a foreign key, but in MySQL that\'s more difficult than it should be. It would require me to go back and make certain changes

Answer 1

They are quite important. You don't want to define your model entirely through PHP. What if there is a bug in your PHP code? You could easily have null'ed columns where your business rules state you should not. By defining it at the database level, you at least get that check for free. You're going to really hate it when there are bugs in your PHP or if any other tool ever uses your database. You're just asking for problem, IMHO.

Be advised, this is the very short version of the story.

Answer 2

The most important thing about using NOT NULL to me, is more the documentation part. When I return to the project after a few months I forget which columns it is acceptable to have nulls in. If the column says NOT NULL, then I know I will never ever have to deal with potential null values from it. And if it allows null, then I know for sure I have to deal with them.

The other thing is, as others have noted: You may miss something somewhere, and cleaning up data sucks, or may be entirely impossible. It's better to know for sure that all data in your database is consistent.

Answer 3

Implement default values and constraints at the database level; rules that will result in acceptable data to any consuming application. This insulates you from integrity issues.

Then, implement better default values and constraints at the application level. If you are prohibited technically (access to APIs external to the database) from implementing a constraint, or generating a default value at the database level, the application is where you'll need to do it. This will result in a better default value. However a segfault, or general failure of the application will not result in unacceptable data being persisted.

Answer 4

I'm usually in favor of declaring constraints in the database. Arguments for constraints:

• Declarative code is easier to make bug-free than Imperative code. Constraints are enforced even if app code contains bugs.
• Supports the "Don't Repeat Yourself" principle, if you have multiple applications or code modules accessing the same database and you need business rules to be enforced uniformly. If you need to change the constraint, you can do it in one place, even if you have many apps.
• Enforces data integrity even when people try to bypass the application, using ad hoc query tools to tinker with the database.
• Enforces consistency which means that you can always be certain the data is in a valid state before and after any data update. If you don't use constraints, you may need to run periodic queries to check for broken references and clean them up.
• You can model cascading update/delete easily with constraints. Doing the same thing in application code is complex and inefficient, cannot apply changes atomically (though using transaction isolation is recommended), and is susceptible to bugs.
• Constraints help databases be more self-documenting, just as column names and SQL data types help.

Arguments against constraints:

• More complex business rules cannot be modeled by declarative constraints, so you have to implement some in application space anyway. Given that, why not implement all business rules in one place (your app) and in the same language? This makes it easier to debug, test, and track code revisions.
• Constraints often involve indexes, which incur some amount of overhead during inserts/updates. On the other hand, even if you don't declare a constraint, you probably need an index anyway, because the column may be used in search criteria or join conditions frequently.
• Constraints can complicate your attempts to "clean up" mistakes in the data.
• In your current project, the incompatibility of MyISAM vs. InnoDB with respect to referential constraints is causing some grief.

Answer 5

You are going to make mistakes with PHP, 100% guaranteed. PHP is procedural. What you want are declarative constraints. You want to tell the entire stack: "These are the constraints on the data, and these constraints cannot be violated." You don't want to much around with "Step 1 ... Step 2 ... Step 3 ... Step 432 ...", as your method of enforcing constraints on data, because

• you're going to get it wrong
• when you change it later, you will forget what you did now
• nobody else will know all of these implicit constraints like you know them now, and that includes your future self
• it takes a lot of code to enforce constraints properly and all the time - the database server has this code already, but are you prepared to write it?

The question should actually be worded, "Why should I use PHP to enforce these constraints, when I could just do it with MySQL?"

Answer 6

Use the database for structural data integrity, and use the BR layer for the rest. And catch errors as early as possible. They work together.

With luck, when your code as matured, you won't experience databse RI errors; and you can proudly announce yourself to be the first.