The Web Database Anti-Pattern

I’m just naming what I’ve seen over and over again.  It’s the extreme polar opposite of the Smart UI Anti-Pattern (in terms of layering) and a play on words of the popular term “Web Application”.

This anti-pattern most often exposes itself as an website (or a webservice/remoting tier) which is merely a thin veneer on top of a relational database.  Logic may be deeply embedded in the database or even very lightly embedded.  The key distinguishing feature is the amount of reliance on the database.  This may come in the form of direct database access in the code-behind or in a very thin implementation of Transaction Script.  All forms of searching and sorting occur inside the database engine.  Application logic rarely goes beyond property-setting and data validation.

While you can successfully build small websites using this anti-pattern, the architectural qualities of an application built with this anti-pattern force it to scale at the database level.  At it’s worst, the database server will max out before the first webserver in load testing.  In milder forms, you may get a web server or two in front of the database (but just barely).

From a conceptual standpoint, the data model is seen as “the one true model”.  Thus any attempts to manipulate or access the model require database roundtrips.  In the worst offenders, data validation only occurs through database constraints.

Refactoring an application using this antipattern is very hard to do.  The bidirectional relationships available and used in the data model tend to break all attempts at using proper encapsulation when building a corresponding object model.

A team working on such an application should do a skills evaluation first and foremost.  I think these types of applications are mostly built in ignorance.  The team may have an expert command of css, html, javascript, and t-sql, but lack real exposure to things such as OOA/D and the basic patterns of application architecture.  This results in a high number of tactical solutions with very few strategic decisions.

An application with an anemic domain model has a high probability to exhibit this anti-pattern.

If your application returns datasets from webservices, there is also a very strong probability that it falls prey to this anti-pattern.

If this does describe your application, don’t feel too bad.  I’ve built plenty of these in my past (which is why I can recognize them pretty easily).  It just takes a bit of reading and some practice to grow beyond this style of development.  But I would recommend starting down the road to growth ASAP. :-)

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

13 Responses to The Web Database Anti-Pattern

  1. Oh wise Evan, please break it down for us. How do we get out of this mess?

    You left out the part about deep attachment between XML and the database, by the way :)

    What are some recommended courses of action? Also, what about the new paradigm of having a rich client (JavaScript/JSON, soon C# in Silverlight perhaps) talking to web services (via JSON or POX) and how that affects the overall design choices and ultimately somewhat depends upon an anemic domain model since your JS objects can’t be too smart now can they…

    Thoughts? Discuss?

  2. Jimmy Bogard says:

    Would you put RoR apps here? They’re pretty much doing a bounded context for the model that separates strictly web-only concerns from other back-end systems.

  3. Evan says:

    No, not by default. I’m not a rails guy, but as I understand it, it forces you down the MVC approach. In that approach (when done correctly), the model does the heavy lifting. An app built with the Web Database Anti-Pattern typically just uses the “application” as an extra layer or tier that the data passes through.

  4. Robz says:

    This usually comes from those who have a background in “the database is the business/application layer.”

    You mean there are layers between the web and the database? No WAY! :D

    Would this bring forth an argument about whether it is wise to turn on and use the CLR inside of SQL Server 2005?

  5. Joe Ocampo says:

    OK Two points.

    > An application with an anemic domain model has a high probability to exhibit this anti-pattern.

    Is your point based on the fact that the behavioral context of the architecture are left outside of this tier and it is merely a representation of Data Elements? If so how do you explain pure DDD models that have Value objects that do not necessarily map to another table but require composition in their hydrated to anemic state within an Entity.

    >But I would recommend starting down the road to growth ASAP. :-)

    Show us some refactoring bro! :-)

  6. Hi Evan,

    I’m going through this transition now but I am faced with two problems:

    1. I am proficient with T-SQL and can’t help but feel that many rules and queries are most efficiently implemented by the database.

    2. What does an application “done right” look like?



  7. Evan says:

    > Is your point based on the fact that the behavioral context of the architecture are left outside of this tier and it is merely a representation of Data Elements? If so how do you explain pure DDD models that have Value objects that do not necessarily map to another table but require composition in their hydrated to anemic state within an Entity.

    If you can show me a good DDD application with only value objects, you’ve got me. Otherwise, there’s a world of difference between an application with a mix of value objects/entities and an application with all value objects (ie.. not DDD).

    As for tiering, in applications which exhibit this anti-pattern, you might only have two tiers, the and the data tier (the database server). Although sometimes you will also see it in three tiered architectures as well, where the application tier really surves no purpose than as a simple data conduit (ie..datasets through webservices). In fact, in these three tiered apps, it would often be more productive for the team to kill the application tier altogether. It typically serves very little purpose (other than just another thing for the team to work on). The logic is either in the UI (Smart UI Anti Pattern) or in the database (Web Database Anti Pattern).

  8. Joe Ocampo says:

    Evan I am having flash backs to the days of DNA where I raised the same question about the app/data tier. Took me a while to convice everyone that one of the tiers has little value.

  9. Brad Mead says:

    I’m definitely in the Smart UI Anti-Pattern world.

    This is yet another great launching point. After all the first step to tackling a problem is identification and the Smart UI Anti-Pattern sounds a lot like my particular ailment.

    BTW – I haven’t seen you post anything on the ALTDOTNETCONF list — I believe your presence there would be a benefit for you and others. (prod :-)

    Thanks yet again Evan for thinking of (generally) and helping (specifically) this self-proclaimed noob.

  10. One of my first assignments when I was finishing up college was to work on one of these applications.

    The database was actually the guts and logic behind a really complicated Access front-end that we were replacing, so it makes sense that the logic would be defined in one place (the db) so that our new ASP.NET front end [strike]could take advantage of it[/strike] not break the rules.

    Eventually it became a humongous pain in the butt to deal with, because it involved so much more “code” to express logic. Often it required multiple stored procedures and triggers to accomplish things.

    We started building out a domain model (a very elementary one, since I didn’t really know what I was doing) but it helped a lot. It abstracted a bunch of advanced rules into one class that we could interact with and sort of “forget” what the database was like underneath. It worked fairly well.

    That’s definitely a pattern I’ve seen, and it takes a lot of time and effort (and usually supporting 2 places for “logic” until you can fully migrate away from the db — for logic that is)

  11. Evan says:


    We could almost give that another name..

    Three Tiered Database Anti-Pattern


  12. Brad Mead says:

    @Ben ditto (prod :-)

    OK i’ll shut up now.

  13. Joe Reddy says:

    If I agreed more it would hurt.