Here’s a New One: SQL Server Relations are Evil

I am doing some work on a three year old WinForms app with its data store in SQL Server and noticed that there is not a single table relation defined in the whole DB. When I asked about this the response was that it was “by design”.

The given reason was that relations “make working with the data a lot more difficult.” Leaving them out “allows the developer the flexibiliy to add the data in the order they choose. It also makes importing data a lot easier”. My respondent ended up by saying that “from real life experience, it’s a trade-off that I can live with”.

This is one of those technical compromises for expediency that I think builds up a debt that will come due someday. Granted, at least the integrity rules for this DB supposedly are correctly implemented in all stored procedures rather than within the application code. This means that when the inevitable third-party DB access is needed, there is theoretically a safe, controlled interface by which they can manipulate the data. But I’d rather get the rules implemented for free by the DB engine. I regard relations and other integrity constraints as a “safety net” to guard against rogue application logic, wherever it may be.

I can’t imagine that the time to write and debug integrity rules in SPs is less than coping with relations when doing an occasional import. That’s why I’m skeptical that integrity enforcement has been consistently and correctly implemented at the SP level. If relations had to be swatted aside as an annoyance then I can’t imagine someone expended an even greater amount of effort to manually implement integrity enforcement in each and every SP.

Having been around long enough to remember working back in the bad old days of apps built on top of monolithic proprietary “4GLs”, I’ve worked both with and without a safety net. I prefer to have one.