In my experience, wrapping all data manipulation operations in a set of stored procedures usually provides abstraction layer powerful enough to address the issu

In my experience, wrapping all data manipulation operations in a set of stored procedures usually provides abstraction layer powerful enough to address the issues raised by the author. In this approach, no application can change data in the underlying tables directly. Change can only be done by calling appropriate stored procedures. This rule is not optional but mandatory and is enforced by database permissions given to the database account used by each application: grant access to stored procedures, deny DML access to the tables. As an example, if customer name needs to be updated, client applications will call procedure called update_customer_phone (customer_id, new_phone) instead of issuing a direct SQL statement like update customers set phone = new_phone where customer_id = XXX There is no need for the application to know that table named customers even exists. Read access should be provided through views and not to tables directly. Views provide abstraction layer that will insulate applications from underlying table changes. While this might seem like a lot work, this approach ends up saving a lot of headache in the long run, especially when one database is used by multiple applications. The main problem with this approach is unfortunately company politics. In many organizations, the only people who can change stored procedures are DBAs or a group of "database developers". The applications themselves are maintained by "application developers". Usually these are separate groups, reporting to different people with different priorities and getting them to work together is often times challenging.