We use exclusively stored procedures, so if we want to add a FK constraint while the application doesn't adhere to it, we do one of two things: Either add it t

We use exclusively stored procedures, so if we want to add a FK constraint while the application doesn't adhere to it, we do one of two things: Either add it to the application and push out a new version. Or handle it within the stored procedure. Additionally, there would be the option of updating the database when pushing a new software update out. > If your data is well architected so that you only have a single representation of each piece of data, sure. Equally if your application is well architected you can have a single API where any given thing happens. I think I formulated it badly before. In this case I meant that we have one stored procedure for each thing we do. So that, if the underlying data changes for example, we only need to change the procedures directly acessing it. We can then call those procedures from multiple different parts of the code. And the procedures are all managed within one application, mssms in our case, where you can have a much cleaner structure than within code. In my experience, in PHP for example, you tend to write VERY similar/same queries in multiple locations, which can cause you to find it harder to all instances.