Repeat after me: Referential integrity is a DB concept.
Recently I was discussing how to introduce a domain model into an environment that currently revolves around the database. Everything is in terms of the database. Everything.
While discussing this architectural decision with the client, I was surprised by the following question:
“How are we going to represent the foreign key constraints & referential integrity within the object? Can we set some ‘triggers’ to check for that stuff when the objects are used?”
I then had to explain that referential integrity constraints had a couple of properties:
1. They enforce normalization
2. They are automatically enforced by the database
Now, you can see from 1. above that not only is referential integrity a database concept, but it actually enforces another database concept, normalization. Now, add the fact that normalization is a OPTIONAL database concept, and you have a tough time trying to justify why it should be represented at the object layer.
As for 2., I can understand why the client would like to enforce the integrity because it prevents invalid data. This is very valid and warranted. But, since referential integrity is a database construct, it’s actually enforced by the database anyway, so as long as the constraints are setup properly, nothing will be allowed to put invalid data into the database, not a object model or a vanilla SQL statement. This alone makes it unnecessary to replicate the constraints at the object level for validation.
Also, let’s say you wanted to replicate the constraints at the object level. How exactly would you accomplish that? Either you are calling to the DB for every single column that has a constraint placed on it, in order to verify the data provided is valid, or you are constantly loading up the entire foreign key list to check against.
Either way, that’s a LOT of overheard just to validate something that will be validated ANYWAY. People need to learn that the database is not the be all and end all of a system. Even if it is, design & performance decisions that are made at the database level should not be pushed up to the developers.