August 23, 2006 at 8:40 pm
This thread made me laugh: Say it with me “Databases don’t scale, application servers do.” We could both eat grass too, but it probably doesn't mean we're cows. Any mutli-threaded app can scale. I've crashed far more app servers than database servers due to merely running out of resources though.
Put business logic where it makes the most sense. If you change your business logic as often as you change your shorts, then put your business logic wherever you can develop it the quickest. Often that is a personnel decision, not a technology one. I.e. if you have 3x the .NET developers as SQL developers, then maybe it should be coded in .NET. If the reverse, then code it in SQL. In many cases either place would do just fine. In SQL 2005 the line is even more blury. Please don't design your apps solely based on the possibility that you might someday have to port your app to another database platform. You're just as likely to have to port your GUI to C-flat-plus-minus in a few years.
Keeping your data consistent and clean is done at the database level and that often goes far beyond mere referential integrity. It's also common to put business logic in the database if you're tables are being hit from multiple apps or other database jobs that may not have their own GUI.
Do you really want 3 different development teams coding "similar" business logic for the same set of tables? The devs probably don't code in the same language and there's a pretty decent chance they won't even speak the same language. Even if they did, you're unlikely to have them all developing at the same time, so that one small table change for team A could completely destroy team B and team C's GUIs if they all wrote their own business logic.
I think this author has sat in on one-too-many theory-laden seminars and could use a bit more time in the trenches of database-centric application development. The article is a year old though, so perhaps it was a passing fad.
August 24, 2006 at 5:42 am
I disagree with virtually everything he said. I only hope nobody listens or agrees with this article. Geez...
August 25, 2006 at 4:17 pm
First, some comments on items in the article or posts...
> I will acknowledge how tempting putting logic in the database is
How do you define "logic"? Do data integrity rules count as logic? Others have broached this very question. A common example that makes the demarcation between integrity and "business rule" fuzzy is referential integrity. One could argue that it is a rule that a parent row must exist prior to adding the child row. I agree with Adam but will phrase it slightly differently. Data integrity rules span all applications and should survive changes in the middle-tier.
> Flexibility decreases as logic increases.....
NO! This really should be "As flexibility increases so does *complexity*." Stating that logic increases or decreases makes no sense.
> What I am saying is that the database can not and should not decide what is valid data.
Taking this concept to its extreme you could end up with multiple applications writing different data into the same column and ending up with crap. App 1 could think that only values FOO and BAR are valid while App2 might only think that CRAP and MORECRAP are valid. While it is true that the applications decide on what valid meaning can be derived from the data, the database should not trust that the application wrote that data correctly. The database should *also* check that data for validity. Those rules should be apply any and all applications otherwise it is different data.
> Databases can be designed to scale out but it is not as easy as
> scaling up, most consultants take the easy road
This is backwards. Databases scale UP easily. Scaling UP refers to putting the database on better hardware. Databases do not scale OUT easily. Scaling OUT means adding additional database servers that work in a cluster or load balancing environment.
August 25, 2006 at 4:20 pm
IMO, the best way to think about this is using the Fiefdom analogy. Think of a fiefdom as a self-contained system. Messages/data can be sent into the fiefdom and it can send messages/data out. The systems that talk directly to a fiefdom use emissaries to review messages/data to help improve the odds that the messages/data will be accepted. However, when messages/data come into the fiefdom it will re-check the data regardless of who submits it.
Taking this analogy to typical n-layer systems (as opposed to n-tier), you typically have three layers: presentation, middle-layer, and a database. Presentation only talks to middle and middle talks to the database. When data is sent from the presentation layer it is checked before being submitted to the middle layer which checks it again. Why? Multiple applications can submit messages/data to the middle layer. The middle layer cannot assume that those applications have done the proper checks. When the data is submitted to the database, again that information is checked for the same reason the middle layer checks it. The database cannot guarantee that the system sending it data as properly checked its information.
If you can prevent any and all access to the database except through your service layer, then you can indeed put all of your logic, including data integrity rules into your service layer. However, in my experience, this type of guarantee is a fool’s hope. Companies get bought, new systems get built, additional teams build more applications and report generators access the database directly are just some of the scenarios where this lock tight control on the database access is lost. A database should be designed with the assumption that some nutty app developer will try to write crap into the database bypassing any middle layer code.
Viewing 4 posts - 61 through 63 (of 63 total)
You must be logged in to reply to this topic. Login to reply