The bounds of a database should be determined by that data which needs integrity between its various elements. This is for disaster recovery purposes, if for no other reason. For instance, if it becomes necesssary to recover employee information to a specific point in time by restoring database backups and logs then most likely all information related to the employee should be recovered to that point in time to maintain integrity. However, if data, like product inventory, is kept in the same database as the employee data and it becomes necessary to recover the employee data to a specific point in time than the product inventory data would also be restored to that point in time, which most likely is not what is desired.

As far as stored procedures go, we try to avoid using stored procedures for those application we wish to be portable across DBMSs since stored procedures tend to tied you to a single DBMS. We have found most performance problems we have encountered are due to poor database design (lack of data normalization) and performance improvements gained by improving database design outweigh those gained by simplying putting queries into stored procedures.

There is an advantage to using stored procedures if most of the logic of an application can be delivered using stored procedures; application logic (that logic which resides in the stored procedures) can be changed without having to redistribute the application. Also, if stored procedures are utilized properly the amount of data being passed between the database and the application can be reduced allowing for better network utilization.