June 5, 2008 at 8:31 am
ageuni (6/5/2008)
I understand this is a SQL Server forum and as such the majority of readers are going to be database enthusiasts, so I'm anticipating some flaming, but here goes regardless.
I don't think anyone will technically flame you but they may post a very strong opinion. At least I hope not.
However, if you go back to what I have posted I think portability is an ideal situation that just cannot be met in most cases due to differences in the foundation of each database system. You have to be versed on the different systems to understand the fundamental key differences as to how you would write a fully portable query. And besides, most companies are unwilling to pay for someone with that much knowledge and if they get someone cheap odds are they will move on quick.
Additionally, why would you invest in a tool with a set of enhanced features you never plan to use. I go back to my statement that if storage is all you are looking for the consider a flat file (there are ways to do indexing and RI even with flat files but if you need something a bit more robust there are systems that are stripped down to just storage w/Indexing and RI or you can find source code for Lite SQL servers that do this to role our own). BTW RI is with relation to each record but things like constraints such as balance cannot be lower than 0 are business logic which you want enforced at the database level and the "no business logic" rule is broken if you choose to create a constraint for this. So to an extent even those who harp on it are not true purests (but I have met a few).
All that said I think there can be a mix of Business Logic where some has specific impact to performance and integrity from the database standpoint or to that which is solely an application level logic that should avoid unneccessary trips to the database to enforce. Each person has to find the right balance, and only if you must develope for portability should you focus here. Because, if you have no plans to change systems why then not take advantage of preformance enhancing features. And if there is an off chance you do change systems later truely how long will it take to do so and I suspect the old system will remain intact until ready to move. Or do you think your application may ever deal with multiple backgrounds for the same features against data where you would have a mixed environment (I highly suspect this is very rare, but that is not to say someone hasn't decide this was a smart idea).
June 5, 2008 at 9:28 am
ageuni (6/5/2008)
So in answer to the original post, businesses talking about putting business logic back into the application means they are correcting bad architecture choices made early on. They should never touch RI, indexes, keys, data. Many old systems have crammed business logic into stored procedures and this is a bad practice. The purpose of tiering applications is to promote pluggability and reusability. I should be able to move from one database to another with the same structure and have a system function identically. I should also be able to plug a new system on top of the same database and interact with the database intuitively and not create a whole new set of stored procedures for the new system. Stored procedures are the gateway to a well kept database and should reflect the database, not the aplication sitting on top of them.
Let me start by saying that I've been at the receiving end of some of the abuses of stored procedures doing much more than was appropriate, so I can to an extend understand some of the backlash.
That being said I find it interesting that there is a lot of resistance to looking at stored procedures as an abstraction layer. It's a very effective encapsulation method, securable, optimizable, allowing you to change behaviors in the surrounding layers without having to change both.
Like Antares has already brought up, database are much more than a simple storage mechanism, and have capabilities that cannot be replicated easily outside of the respective DBMS'es. Concepts like "current inventory" or "prior balance" are shot through with Business logic, and like it or not are just about impossible to replicate on a client-side layer without giving up every ounce of performance you ever had.
The layer concept isn't perfect either. Like it or not - layers can often be bypassed, so having a "perfect" business layer that gets accessed 99% of the time, and bypassed just 1% of the time, means that you will now have some amount of garbage in your information. And like it or not - more important than the application is the data it tracks, so allow that junk in should not be acceptable. So key items (that are appropriate to enforce on the data layer) SHOULD be enforced there. I'm talking data integrity, and not necessarily relational integrity.
Finally - as has been pointed out before - you can't get performance out of an "objective" approach to data storage and organization. Like it or not, you CAN build an application to work equally well based on data from an Excel spreadsheet or a Clustered SQL Server Enterprise setup. Of course - your Clustered SQL Server will probably be performing at about .001% of its potential, and what a waste that would be.
There have been several MSDN bloggers (I will see if I can dig some up) who have pointed out accurately IMO, than the "business layer" should not be considered to stop as soon as you cross into to the DBMS realm. You should instead be conceptually looking at sub-layers, and one of those sub-layers of the business layer resides on the RDBMS.
I find that as a developer in certain busy shops we tend to forget that while it's great to have a lot of convenience DURING the development stage, the more important aspect should be what you have AFTER you develop. The purpose of development is to build something you don't have to develop any more, so being able to develop fast something that runs is important, but being able to develop something that runs fast is even more important.
Good discussion, though....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 6, 2008 at 2:19 am
I've seen many discussions of this nature before, including here at SQLServerCentral, and they typically tend to suffer from the lack of a definition for "business logic" (although in reality I suspect we're not typically including DRI here).
I have worked on many applications where the goal has been to locate all "business logic" in a single location, such as a Business Services layer. The term "goal" tending to mean: do it this way unless there is a compelling reason not to. The term "business logic" has tended to refer to business rules such as validations, defaults, and calculations that
operate on the business object model.
It should go without saying that any solution (best practice aside) should be appropriate to the problem being solved. Not all applications have thousands of users and a trillion tons of data or require multiple physical tiers, so putting all the business logic into a single logical layer might be appropriate and workable. I'd expect the distribution of business logic to increase somewhat in proportion to the (network) distance between the client and the server.
Portability isn't always the reason for putting all the business logic into a single location -- the most common reasons that I've come across are performance, scalability, and maintainability.
In terms of bypassing layers -- and I'm gonna have to hold my hands up at this point and admit that I'm no expert DBA -- what's the proposed solution here? Put all the business logic into triggers?
Also, we can't ignore nontechnical constraints. I've worked on projects before (and I'm not saying this is a great idea) where getting it done quickly/asap has been deemed the primary goal!
I think that most posts on this topic have raised some good/valid points, even when they appear to contradict each other. The thing to remember is that there is no single perfect solution and all situations are different.
June 6, 2008 at 8:07 am
re: Definitions
In my mind, the data model *is* business logic incarnate. The objects and relationships expressed though the model's design are nothing if not business logic. (I'm not saying that all of a business' logic can be captured in the model.)
Otherwise, what's the point of an RDBMS?
This is why I shudder when I see DBs with no DRI; tables where every column is nullable; and developers who want all the foreign keys dropped because otherwise deletes have to be in "some sort of order".
June 6, 2008 at 8:14 am
I think in order to provide any meaningful feedback to this post we need to know the definition of "business logic" provided by the Development Team of Knight (original poster). There are always extremes, however, the situation may not be as bad as imagined. On the other hand, it could be just as bad as imagined! 😀
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply