Isolation: You could use technologies like LINQ to loosely couple your implementation with the actual database implementation, but there is a cost associated with this level of isolation. The reasoning behind the approach of refraining from implementing extensive logic in stored procedures, especially triggers at the database layer is that doing so greatly reduces visibility to program logic in the code thus making the task of understanding logic a two-tiered task.

Abstraction: A better strategy is Abstraction. Irrespective of database, certian functionality is very common to across all databases. Methods like CheckDatabaseConnection(), RetrieveDatabaseQueryString(), ConnectToDatabase(), ExecuteQuery(), ExecuteScalar(), ExecuteSqlStatement() are used by applications irrespective of the database. This is where it makes great sense to use a Database Access Layer (DAL) component that ensures that the database connectivity is always happening through a centralized unit of code. Therefore, if there is ever a need to make changes to the database integration, for example, if you wanted to log the time before invocation and after result delivery to see if database access is a bottleneck this could be implemented in the DAL component instead of changing every block of code in your application that accesses the database.