When developing applications (for simplicity, use a client-server model) intended to be deployed on customer systems, when it is acceptable to expose business logic outside of compiled code (for instance in stored procedures)?
I used to subscribe to the thought that any and all logic should always be within the compiled code as it is both protected from being altered in addition to providing a level of IP protection. However, after distributing a few small client specific applications relying heavily on stored procedures, I have found that the ability to make fixes/customer specific adjustments "on the fly" (responsibly, of course) directly in SQL has made both support and maintenance significantly easier and faster as a change doesn't have to be compiled.
I do realize the drawbacks of this approach:
- Anybody with DB rights could change the behavior/break the application without you knowing
- Version control difficulties
- Some loss of IP protection
Assuming the platform will always be the same (no need to support multiple SQL DB's) and the application could be deployed by multiple distinct clients, does it make good sense - from a development and business perspective - to allow business logic to exist somewhere it is relatively easy to view and alter?