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?
7
Anybody with DB rights could change the behavior/break the application without you knowing
There is relatively simple protection from this: just write it in your contract that as soon as someone manipulates your product, you will refuse to do any maintenance any more. Add also a note that with each new release of your software you will replace existing stored procedures by new versions. This will hold most customers back from changing things they should not change.
Version control difficulties
Why should these be different than for client-side code? Since you wrote it is a standard product, you should separate customer specific changes / parameters rigorously from the source code of your product. There is no general difference for client code or server-side code in this. When you follow this rule, version control for your server-side code should be as easy or as hard as for your client-side code.
Some loss of IP protection
I would not overrate this. As long as there is no “ground-breaking, totally ingenious algorithm” hidden in your stored procedures, I guess the code is not of much value to anyone else as long as he has not also the client-side source code of your application. Moreover, for some database systems there are also options available to hide or obfuscate stored procedures – Google is your friend.
So the gist is: try to deal with your server-side code the same way you deal with your client-side code, then your “drawbacks” will vanish.
1