Why is "business logic" in the database bad


General J2EE: Why is "business logic" in the database bad

  1. Why is "business logic" in the database bad (3 messages)


    I'm continually being told that I shouldn't put "business logic" in the database. That it should all be in the middle tier.

    In practical terms this seems to be a ban on stored procedures. Sometimes using a stored procedure seems to me to be the sensible choice. And yet they are banned.

    So, my questions are:

     * Why is there such resistance to business logic in the database.
     * When is it smart to put business logic in the database.

    Thanks a mil,
  2. Generally, the idea is to be storage-independant. This means, that if one day you decide to change your database, it shouldn't affect your application and code. Atleast in theory.

    In reality, as always, there are other considerations, such as performance, learning-curve, ease of implementation, etc.

    So technically, its up to you to decide when and when not to put code in the database. I usually prefer the middle tier, except in cases where I know for sure that db-code will perform much better.

    Hope this helps,
    Arik Kfir
    Project Manager
  3. Why is "business logic" in the database bad[ Go to top ]

    The answer goes back to the benefits of having an n-tier architecture(as is the case with J2EE based architectures) vs a 2 tier architecture(a client server type of architecture where the server role is assumed by the database and the business logic and data is intermingled in it)

    For a more scalable and pluggable architecture it is always better to have your business logic reside in the business tier and the data in the resource tier(database). This way you can make your system more scalable since each tier is differentiated by their assigned roles and responsibilties, so if there is any change in the logic, only the component that contains the specific functionality is affected and can be updated easily.
    of course there are trade off's between performance vs scalability and manageability and depending on the nature of application you would have to decide if is ok to have business logic tightly coupled with data(stored procedure approach) or a tier based architecture is preferrable.

    hope this helps
  4. As the previous gentleman pointed out, we don't just develop just for functionality sake. For mission critical systems, we need to devote our focus on the scalability and the high availability considerations. Sometimes, it is recommended to push the stateful information to the database server assuming that the database is highly available. However, in (geographically) distributed architecture, it is a challenge to replicate these database servers.