That sounds fine - all business logic in the database. This may be good for having one place where all logic is defined and for performance reasons.
What can you say about the arguments that have been raised frequently against having all business logic in stored procedures?
Some of the following good practices/ patterns cannot be easily implemented in stored procedures.
- Interfaces to allow re-usability swapping of implementations and testing dependencies.
- Dependency injection management and avoiding an untraceable tangled web of stored procedure dependecies
- Documentation similar to javadocs that can be automatically created as part of the build process.
- Static analysis to enforce programming standards and conventions
- Inheritance, polymorphism to reduce duplication and complexity and allow extension.