Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
ramdas
Posting Yak Master
181 Posts |
 Posted - 2002-10-18 : 14:11:10
|
| Hi All,We have a client server application where the business rules primarily reside in stored procedures. This has resulted in a exponential growth in the number of stored procedures in the SQL Server Database. There is a group of people who want move the business logic to COM Components and make it a three-tier arch. What would be the Case for not putting business rules in Stored procedures?On a Side Note:Q. What is the difference between a Purse Snatcher and a CEO?A. The Purse Snatcher can Run.Thank YouByeRamdas NarayananSQL Server DBA |
|
|
royv
Constraint Violating Yak Guru
455 Posts |
Posted - 2002-10-18 : 15:13:04
|
We have a 3-tier architecture, and the reason I put my business rules in stored procedures is simple. Right now we have an ASP, VB COM, SQL solution in place. I want to migrate to ASP.NET with Managed DLLs and SQL 2000. I will not have to rewrite a single business rule since all of my business rules are in stored procedures. Can you imagine the nightmare I would have of migrating this to a .NET platform if the business rules were in the VB COM? Yes you can have COM in .NET, but then it would not be a true .NET solution in my opinion. Liked the joke by the way.. *************************Someone done told you wrong! |
 |
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2002-10-18 : 16:14:32
|
| I totally agree with royv. It doesn't matter what "data object" talks to your stored procs, they all have to adhere to the same business rules since the rules are in the stored procs, and not the "data objects" themselfs.The only reason I can see to put business rules in your "data objects" is if you don't know T-SQL well enough to impliment your business rules with it. That's a very poor reason IMHO.Put the rules in the stored procs. You'll be thanking yourself down the road.Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2002-10-21 : 12:43:41
|
| >> It doesn't matter what "data object" talks to your stored procs, they all have to adhere to the same business rules since the rules are in the stored procs, and not the "data objects" themselfs.Also if you put the business rules into com objects and all access is via these com objects then you have the same situation.>> The only reason I can see to put business rules in your "data objects" is if you don't know T-SQL well enough to impliment your business rules with it.You could also say that the only reason to put business rules in SPs is if you don't know com.The business logic can reside anywhere - it just depends on the nature of the application.Normally any batch processing should reside in SPs as this will normally require set based processing for efficiency and also need to control resource locking.A major problem with implementing business logic in com objects is transaction control. You will often end up with a lot of deadlocks and blocking as the people who are coding don't know enough about the nature of the database. It will also be a lot slower than anything implemented in SPs.A problem with putting everything in SPs is that you can end up with different servers interacting with each other and even trying to control each others processing. This is usually because the implementers haven't spent enough effort designing the architecture.Generally you will end up with a system more robust, efficient and easier to maintain if you put as much processing as possible in SPs - but only if it is well designed.If you have little expertise in this area then consider whether you have the right team to build this system.No such thing as a 3 tier system really try client server or n-tier.If the business logic is in SPs then it is already in a separate tier.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
|
|
|
Stored Procedures