1

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
  • What kind of application are you having in mind? Software for a specific customer, or some kind of standard product? For customer-specific solutions, do you have really customers so foolish not to grant themselves access to the source code of your application by contract?
    – Doc Brown
    Commented Sep 28, 2014 at 18:46
  • I somehow fail to follow you on this assumption that compiling code provides any kind of "protection". This seems to be a very bad case of security through obscurity. Also: "Anybody with DB rights...", maybe just don't give everybody and his cat admin rights?
    – thorsten müller
    Commented Sep 28, 2014 at 18:47
  • @DocBrown - A "standard" product (I use that loosely here), but something which would likely vary slightly from customer to customer. As a for instance, a utility type application which reads a database from standard product (e.g. a CRM, ERP, whatever system). For the most part the DB structure will be the same, but custom fields could be added to it on each client installation or customer A could be using field X differently than customer B.
    – Jason Faulkner
    Commented Sep 28, 2014 at 18:52
  • @thorstenmüller - I'm not worried about someone ripping off the design (we aren't talking about a game-changing application here), but for business reasons having your code compiled and/or obfuscated (in .NET cases) is usually to satisfy a business need. As for controlling DB permissions, keep in mind this would run on a customer system so permissions can only be recommended, not controlled by the developer.
    – Jason Faulkner
    Commented Sep 28, 2014 at 18:58
  • I think you've weighed up the pros and cons as well as any answer will, with the exception of IP protection, which I suspect you're overrating
    – Ben Aaronson
    Commented Sep 28, 2014 at 18:59

1 Answer 1

Reset to default
0

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
  • Thanks for this. I was a bit wafflely on some of the design aspects (mostly from the business side of it) but it sounds like there isn't really a huge call for concern. The version control procedure will need to be tightened a bit (as all changes wouldn't be to the client source) to handle client-specific configurations, but this is to be expected.
    – Jason Faulkner
    Commented Oct 1, 2014 at 1:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.