Where Logic Lives
-
Well put, Everett.
One may ask whether or not it is good idea to put all the business logic in the application, when a company decides to move from a Java application server to a Microsoft .NET platform.
Businesses may well desire better portability of the application rather than the database, so the better choice would be to keep the business logic in the database. Others want to support several databases, and decide to put the logic in the application.
Oracle has supported object oriented programming in the database for years, first with PL/SQL and then with Java. Microsoft has finally caught up and now enables us to do some sophisticated programming in the database, _if_ we want to. Some systems that I've worked on use that Oracle capability and some don't. It will be the same for applications on Microsoft SQL Server.
If we split the "business logic" into validity/integrity, common must-have business rules, application/work flow rules, and user specific rules, then the placement of the logic should be obvious. That still needs analysis to classify the requirement but its a lot clearer.
-
Interesting topic.
Of course referential integrity belongs at the database, the database has to be responsible for ensuring the data is as valid as posisble.
Scenario: I put my business logic in my database. I find I have performance issues. I tune, I solve some, I buy more hardware, I solve more issues. Now my customer base tripples (or quadruples) and my database is slow again. Now how do I scale?
Do I:
A - Buy more hardware - cause we all know how cost effective those 32 proc Itanium 2s can be.
or
B - Spend untold amounts of money re-designing the database for partitioning.
or my preferred method
All "Business logic" goed into the app servers, the only API to the data is through the app servers. Anyone who touches data without going through the app servers doesn't work for me any more. When my app servers need to scale I buy *more* app servers. they're cheap, they are web servers, serving web services.
I've worked on too many databases over the years with all this "Business logic" built in and when you hit your performance ceiling the only option is to buy bigger because scaling out is nearly impossible. One company I worked for grew their customer base 20 fold over 4 years. IT has to move FAST to keep up with that level of growth.
Michael R. Schmidt
Developer -
Why does everyone think we all flip companies and work in consulting. With all due respect to the consultants here the majority of projects designed by consultants for the enterprise I work for have either fallen way short or failed. Cutting edge here means proving we can do projects ourselves that are better, using the right technology.
Believe it or not I've only written one piece of code that's ever used more than 5% of the server. The idea of maxing out the hardware eight years ago was a concern, now it's a joke. Every single one of my projects require autehnitcation to use or is still stuck with an MS Access front end, we know the scope. MS Access is a real issue as is migrating to web based APIs and trying to make the life of other units easier.
Think outside the Enterprise/Consultant box.
Everett Wilson
ewilson10@yahoo.com -
I can only speak from experience. I was with my last company for four+ years. I worked on the enterprise architecture as the company grew from 1 million to 20 million subscribers and 2000 employees in a central location to 20,000 employees scattered across the country.
I have written many enterprise applications that seriously use (and sometimes abuse) the hardware they run on
In my experience
- Putting business logic in the database can cause performance issues
- Growth can cause performance issues that cannot be overcome by simply buying hardware
- Sometimes you have no choice but to redesign existing architectures - because they were poorly thought out in the first place
- Some projects should just be killed because performance was not designed in from the start and retrofitting performance is a bad business decision
- Designing systems that scale is easier said than done
- Scaling by simply adding a new box (out) is easier than scaling by replacing existing hardware (up)
- Designing systems for 24/7/365 (6.9s) is easier said than done
- Databases can be designed to scale out but it is not as easy as scaling up, most consultants take the easy road
- Management often takes the path of least resistance (what costs me less today) when making project decisions
- The first goal of most consultants is to get management to buy off on their ideas – see 9 and think about the implications
Always keep it simple, but not too simple
Michael R. Schmidt
Developer -
There was a thread on one of the SQL newsgroups where we were discussing Google's databases and the hardware they use to run them. Someone pointed us to a link by one of Google's chief engineers describing their proprietary database and indexing systems designed in-house (as it turns out most of their systems are not SQL-based), and the "throw-away" servers they use to run it all. Interesting stuff.
I'll see if I can locate the articles and post the links here later.
-
A person I work with and who I repect a great deal pointed out that in some of my replies I have sounded like a pompus ass. If you knew me you would find that as funny as I do, but because you don't I would like to appologize if I came across that way to any of you. Also, I think it would be who of me to give you a little background. I am not a full time consultant and like many of you have had less then pleasurable experience with the ones I have encountered. Having said that, I have also worked with and learned from some very talented ones. I have spent most of my career with a company in the financial industry and more specifically derivites trading firms. I was at my last job for over seven years. I have worked with almost all brands of databases in some form or another. I am not a big certification guy so I don't have lots of letters after my name, not that there is anything wrong with that. I have taken classes like most of you with the vendor of choice depending on the product. I have been on both sides of the coin as manager making unrealistic demands of my IT Staff and as a member of the IT Staff recieving those unrealistic demands.
I believe this is an issue that none of us are going to put to bed tonight. Different situations require different solutions and ultimately that is why we are all here, to learn new ways of thinking and doing things. I was responding to an article I read that I thought did a lot to stear people down a road that I had travled and had some less than desireable results from. That is not to say I didn't miss something along the way. I am not the end all or be all to this topic nor do I want anyone thinking that. Take this along with many other things you have read and experienced and figure out the best way to do what you are trying to do for your situation. Most importantly, know why you are doing what you are doing.
-
I agree with Mike wholeheartedly. Forgive me if I came across the same way in my posts.
Sometimes we need to stir things up a bit to bring out the aroma of what's cooking, but we shouldn't make a mess of the kitchen and ourselves.
-
If your "business logic" is changing on an application-by-application basis, it is not business logic. It's application logic. Which does not belong in the database.
Business logic -- logic that is central to the business itself, logic that does not change between applications -- is tightly coupled to the data. If the data does not adhere to these rules, the data is wrong for every application, across the enterprise. That is the primary reason that business logic -- but not application logic -- should be encapsulated in the database.
--
Adam Machanic
whoisactive -
That's what I was trying to say, "If we split the "business logic" into validity/integrity, common must-have business rules, application/work flow rules, and user specific rules, then the placement of the logic should be obvious. That still needs analysis to classify the requirement but its a lot clearer."
Adam, you said it better. Thanks.
-
Some business logic can ber *very* complex and therefore can threaten the databases ability to scale. What we may think is easy today may become very complex 1 or 2 years down the road. Or as I have experienced, the rules may change down the road and a simple if else if else (repeat a ferw more times) might turn into a state machine that damn near defies definition.
My question will always be - what do you do when you are using an 8 proc SQL box - and you've optimized as much as possible and you are still have zero headroom for growth? It is not a fun position to be in.
Michael R. Schmidt
Developer -
Buy more boxes. How much is your business worth if your data is trash?
--
Adam Machanic
whoisactive -
mayhap a cavalier attitude but I just can't resist throwing this in...
logically then, the business logic rules that this is none of the application's business.......?????????
**ASCII stupid question, get a stupid ANSI !!!** -
Actually, that's exactly correct!
These rules are none of the application's business. The application shouldn't rely on them in any way (that is to say, the application should trust the database to do the right thing with regard to those rules.) By encapsulating and completely divorcing these rules from the applications (note the plural), flexibility is greatly increased when the rules need to change in some way. And, as we all know, change is the only constant
--
Adam Machanic
whoisactive -
I should also ask forgiveness if I came across to anyone strongly. Sorry about that folks, I fully buy into the idea of a layer/object shouldn't know what another layer/object is doing. Not that I get it right every time.
Although, I'm not kidding when I say scaling is not an issue but just a phantom in my world. I remember when the unit I was in at the time was constantly worried about bottlenecks. Then we'd stress load way beyond anything in our area we could expect and the box would eat up.
I don't know this for a fact but if I had to guess the reason why we can feel secure in the hardware, I'd attribute it to two items. First, the total number of records involved from all tables rarely going over 100,000 and never over 200,000. Second, even in those systems that have fundamentally changed the business process the total load on the front end maxes out at a few hunded individual uses a day (24/7 but realistically the web load is from 5AM to 2AM the next night). None of these applications have ever scaled to anything radically beyond our expectations. In fact, it's more likely that a project will be reused on another box in another unit. Just the environment.
Everett Wilson
ewilson10@yahoo.com -
Adam I agree with everything you just said, except your definition of business logic. Business logic is the logic that is applied to the data in order to obtian the desired results for that particular business at that particular time. If I work for a trading firm that trades options on equities, equities, futures on indexes, options on futures on indexes and so on. The business logic behind how you trade those products is completely different in each case. I don't want to take that into account each time a trade is added to the database. I want one proc that adds the trade for each of them regardless of the business logic associated with trade.
It would be great if you could speak of a real world example of your definition of business logic (which is where I think the discussion really lies)
Viewing 15 posts - 16 through 30 (of 63 total)
You must be logged in to reply to this topic. Login to reply