You should bear in mind that moving business code to the application does introduce a possible loss of integrity. Does the application assure that every set of interdependent modifications are wrapped into transactions? If you need to change the physical database schema for performance reasons, will the application developer be able to incorporate this change easily in his code? I am both an application developer in .NET and a SQL Server DBA in several larger projects, and sometimes I favor .NET over stored procedures only because my fellow team members are not as familiar with SQL as I am.

Please think twice before you move business logic into the application. If it changes so often, how can any developer assure that 'old' data is still valid for the 'new' code? Who keeps track of all those changes to avoid any flaws an conflicts that might occur at the storage level inside the database? Many developers do not like foreign keys because they limit them severely in the way modifications on the data may be performed. But every 'relation' without a foreign key constraint is doomed to loose its integrity sooner or later.