Tuesday, August 28, 2012

A Religious Discussion

Have you ever heard a DBA prattle on incessantly about the importance of the database and their apotheotic role in maintaining the space-time continuum? Me too. And while databases (and occasionally DBAs) have their place in software, I would contend it is not at the same level as the code or UI.

So I am throwing down the gauntlet to all of you database gurus. I challenge you to construct a lucid, well thought out, logical argument that disproves any or all of these statements:
  • A database is for storing and retrieving data period.
  • Business logic does not belong in the database period.
  • SQL server is not a software development platform period.
Let the conversation begin.
Posted by at

4 comments:

  1. JeremySeptember 4, 2012 at 8:42 AM

    I completely and 100% agree with 1 & 3 but I have heard one good argument about business logic in the database. Column data types, lengths, constraints, etc are business logic. It's a really good point. Maybe we should start saying: minimize business logic to data integrity settings.

    ReplyDelete
  2. Brian RigsbySeptember 4, 2012 at 9:09 AM

    Those types of data constraints should be enforced via input, data, or domain validation before anything makes its way to the data store. Do you want to make a call to the database to determine whether a string should be less than 100 characters?

    ReplyDelete
  3. JoshMarch 5, 2013 at 1:40 PM

    I'm a developer playing devil's advocate.

    One reason to have business logic in something like stored procedures in the database, though it's very conditional. If you have: multiple projects using different development platforms developing on the same database, having one set of stored procedures that contains shared logic can be helpful.

    Though even in that situation, it's not ideal, because stored procedures are hard to isolate and test. You might be better off having a common API all projects consume, though that has obvious performance implications.

    ReplyDelete
    Replies
    1. Brian RigsbyMarch 6, 2013 at 5:25 AM

      When we make a programming decision, it should begin with a principle, something that has been road tested, that we can go back and refer to and study. Once you begin putting business logic into the database, you have abandoned the separation of concerns and are therefore opening up your entire domain to compromises that can lead to technical debt.

      Also, I do not think there are any "obvious performance implications" in an API. How many times have you heard a user complain about a report that takes 10 minutes to load only to discover it was because of a poorly written stored procedure?

      Delete

Subscribe to: Post Comments (Atom)