 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Distributed Applications / September 2005n-Tier Business App - Complex Logic
Hi I've got a n-Tier web application, consisting of SQL Database, DAL , BOL , Web Layers, with about 500 concurrent users. I've come across some complex calculations I have to make and am wondering what the best school of thought is: The calculations are definitely Business Logic. But, they involve many different sets of relational Data, and the idea is that it would probably be faster to write an SP that could handle all the calculations. Is it bad to move business logic and processing into the DB? There is also the possibility that the calculations can be broken down into smaller calculations, and in that case I could process all the smaller bits in parralel using multi threading, where-as I wouldn't be able to do that with an SP ....? What are anyones thoughts on this? cheers Mike > The calculations are definitely Business Logic. But, they involve many > different sets of relational Data, and the idea is that it would > probably be faster to write an SP that could handle all the > calculations. Personally I advise against putting such in an SP. > Is it bad to move business logic and processing into the DB? Yes. This might be of help to you: http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp And: http://www.codeproject.com/gen/design/TierPressure.asp -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs Thanks !!!! That's just what I needed ! >Thanks !!!! > >That's just what I needed ! Unfortunately the articles are completely wrong. It would be a lot better to read a serious book about data management. Regards > Unfortunately the articles are completely wrong. I beg to differ - I would not advise the poster to follow your advise at all. He will have serious issues with maintenance, as well as growth of his system. As you reference "Read a good book" - Please post any reputable book which recommends to use Stored Procedures for business logic in a multi tier design. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs >> Unfortunately the articles are completely wrong. >I beg to differ - I would not advise the poster to follow your advise at all. He will have serious >issues with maintenance, as well as growth of his system. Nonsense. >As you reference "Read a good book" - Please post any reputable book which recommends to use >Stored Procedures for business logic in a multi tier design. What I mean is that you articles are plenty of mistakes, and it should be evident to anybody whith a good grasp on data management theory. A good introduction to the subject is: "An Introduction to Database Systems" by CJ Date Regards > "An Introduction to Database Systems" by CJ Date This book is about managing a RDBMS, not about building multi tier systems. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs >> "An Introduction to Database Systems" by CJ Date > >This book is about managing a RDBMS, not about building multi tier systems. This is a book about the fundamental principles of modern data management, and it is enough to learn why your articles are harmful and utterly wrong. You can not design a good Information System nor to write good articles if you don't know the fundamental principles of the profession. > This is a book about the fundamental principles of modern data > management, and it is enough to learn why your articles are harmful > and utterly wrong. You again are mixing terms. Data management is just one small piece of distributed systems. Many data management people still approach all systems as 2 tier client server. Im sure this book is excellent about tuning databases and such, but in its synopsis I see no mention of it being a n-tier design book. Read some books on n-tier design to put this book in context. Reading a book about how to efficiently write X86 assembly language and desing aspects of the Intel processor line and then applying this to object orient programming in .NET will not provide a good background - and this is exactly what you are doing to n-tier systems. You should really expand your horizons a bit beyond one small field, and stop proclaiming to be an expert as you seem to have done on several ocassions. I especially enjoyed the thread where you disputed an acclaimed mathemetician. -- Chad Z. Hower (a.k.a. Kudzu) "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs >> This is a book about the fundamental principles of modern data >> management, and it is enough to learn why your articles are harmful >> and utterly wrong. > >You again are mixing terms. Data management is just one small piece of distributed systems. Data management is the goal of all Information Systems, distributed or not. > Many >data management people still approach all systems as 2 tier client server. Im sure this book is >excellent about tuning databases and such, but in its synopsis I see no mention of it being a n-tier >design book. Read some books on n-tier design to put this book in context. The book is about the fundamental principles appliable to any Information System. Principles you showed you don't know. You have to learn a lot before you can discuss about the specific aspects of distributed systems. Remaining nonsenses snipped. Regards > Data management is the goal of all Information Systems, distributed or > not. But your statements do not apply to data management, but by your own statement business logic. Business logic is not data management. Consulting a data management book on how business logic should be done is the root of your mistake. Many data management books touch on business logic - but just because they touch on it does not mean it applies in all sceanarios, is a modern, or even a correct approach just because data management is one (and only one, not even the primary) aspect of distributed systems. If you read a text about formula written by a mathemitician - and it lists the best ways to solve and perform calculations - that does not necessarily hold true when a computer is used. OFten different paths are used because of how computers handle numbers and following a mathemiticians strict advise will yield poor results - becuase the mathemitician was writing from a mathemiticians view - using formulas worked out by hand, or calculator. The mathemetician does not understand how computers store numbers, or how CPU's can more efficiently crunch them. > The book is about the fundamental principles appliable to any > Information System. Principles you showed you don't know. By your own statemetns you were a data newbie 18 months ago. What in the past 18 months has made you an expert? Does reading a book make you an expert? > Remaining nonsenses snipped. You mean your posts I pulled out of Google? I agree with you here - then nonsense was snipped. -- Chad Z. Hower (a.k.a. Kudzu) "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs >> Data management is the goal of all Information Systems, distributed or >> not. > >But your statements do not apply to data management, but by your own statement business logic. >Business logic is not data management. You can't be more confused! > Consulting a data management book on how business logic >should be done is the root of your mistake. I have readen dozens of serious data management books and all of them support my position (an incontrovertible position). But you have admitted you have not readen the standard introduction to the data management field. Here you have a very good starting point: http://www.dbdebunk.com/books.html Which book did you readed? It is evident that you only readed very bad data management books written by afficionados. It seems the source of the problem. Business logic in the context of an Information System is nothing but data logic: data structure, data integrity and new data derivation. Data management in a short. >Many data management books touch on business logic - but just because they touch on it does not >mean it applies in all sceanarios, is a modern, or even a correct approach just because data >management is one (and only one, not even the primary) aspect of distributed systems. Many data management books are written by ignorant afficionados, and they are very bad. Data integrity and new data derivation (what you call calculations) are essential parts of data management. A database book that does not cover data integrity and derivation in depth is a very poor book. >By your own statemetns you were a data newbie 18 months ago. What in the past 18 months has >made you an expert? Does reading a book make you an expert? You are wrong again, you failed by a lot. But what makes you an ignorant is that you haven't readed any serious data management book, and it seems you are not willing to read one. It is probably that you were misleaded by other dare unskilled and unaware of it afficionado writters, and you are misleading more people. This is a very frequent vicious circle on the net. >> Remaining nonsenses snipped. > >You mean your posts I pulled out of Google? I mean your comments. >>should be done is the root of your mistake. > > I have readen dozens of serious data management books and all of them > support my position (an incontrovertible position). Again - data management. You seem to have no background in mult tier, and your data management is limited to 18 months. > they are very bad. Data integrity and new data derivation (what you > call calculations) are essential parts of data management. I never called them calculations - I was proposing an analogy. You made the link between the discussion and calculations. > A database book that does not cover data integrity and derivation in > depth is a very poor book. You are brining in items that are not part of the original statement. Your statement is that stored procedures are an excellent way to implment business logic. Business logic is not data management. >>By your own statemetns you were a data newbie 18 months ago. What in >>the past 18 months has made you an expert? Does reading a book make >>you an expert? > > You are wrong again, you failed by a lot. Im using your own statemetns, retrieved by Google. > But what makes you an ignorant is that you haven't readed any serious > data management book, and it seems you are not willing to read one. > > It is probably that you were misleaded by other dare unskilled and > unaware of it afficionado writters, and you are misleading more > people. This is a very frequent vicious circle on the net. You have no idea of my background, its obvious you havent even taken a second to Google. Where as Google on your name turns up repeated discussions on various topics where noone agrees with you, yet you persist your views, even when arguing with recognized experts. -- Chad Z. Hower (a.k.a. Kudzu) "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs >>>should be done is the root of your mistake. >> >> I have readen dozens of serious data management books and all of them >> support my position (an incontrovertible position). > >Again - data management. You seem to have no background in mult tier Multitier is only a minor aspect, and there are several kinds of tiers. I know more about distributed systems than you imagine, but you can't know how to build a good multitier system if you don't have a clue on the fundamentals of the data management field. You can not command rocket science whether you don't know elementary algebra and calculus, that's evident. For instance you confuse logical and physical tiers all the time, and you don't know that a business logic server is nothing but a DBMS. >> they are very bad. Data integrity and new data derivation (what you >> call calculations) are essential parts of data management. > >I never called them calculations - I was proposing an analogy. You made the link between the >discussion and calculations. It was Michael. >> A database book that does not cover data integrity and derivation in >> depth is a very poor book. > >You are brining in items that are not part of the original statement. Your statement is that stored >procedures are an excellent way to implment business logic. I never said that! Stored procedures are procedures like any other (also called methods), and procedures are the worst way to implement business logic. It is a lot better to use declarative code. But business logic is a responsibility of the DBMS, so the business logic implemented procedurally should be enforced by the DBMS anyway. BTW "stored procedure" is a bad name because they are not more nor less 'stored' than any other procedure. For instance you can buld a DLL using C# and to use it from SQL Server. >Im using your own statemetns, retrieved by Google. Where? >You have no idea of my background I don't care what your background is, but you have proven you don't have a clue on data management theory, which is an essential skill to develop good Information Systems, distributed or not. >, its obvious you havent even taken a second to Google. I was aware of who are you, but there is nothing impressive. > Where >as Google on your name turns up repeated discussions on various topics where noone agrees with >you, yet you persist your views, even when arguing with recognized experts. There are many truly recognized experts who fully agree with me, and I mean truly internationally acclaimed experts, and not MVPs, BorCon speakers and the likes. Regards >I've got a n-Tier web application, consisting of SQL Database, DAL , BOL , Web Layers, with about 500 concurrent users. > >I've come across some complex calculations I have to make and am wondering what the best school of thought is: > >The calculations are definitely Business Logic. But, they involve many different sets of relational Data, and the idea is that it would probably be faster to write an SP that could handle all the calculations. Perhaps, but generally speaking it is a lot easier to implement the business logic using declarative code (views for instance and assertions for instance). Stored procedures should be used only when it is not possible to use declarative code. >Is it bad to move business logic and processing into the DB? Of course not! DBMS's are exactly for that. >There is also the possibility that the calculations can be broken down into smaller calculations, and in that case I could process all the smaller bits in parralel using multi threading, where-as I wouldn't be able to do that with an SP ....? A good DBMS should take advantage of multiple processors. Regards Alfredo > Perhaps, but generally speaking it is a lot easier to implement the > business logic using declarative code (views for instance and > assertions for instance). Stored procedures should be used only when > it is not possible to use declarative code. Easiest is not always best - in fact it rarely is. >>Is it bad to move business logic and processing into the DB? > > Of course not! > > DBMS's are exactly for that. No they arent - SPs were never designed for such. You will find very few people who agree with your position. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs >> Perhaps, but generally speaking it is a lot easier to implement the >> business logic using declarative code (views for instance and [quoted text clipped - 11 lines] >No they arent - SPs were never designed for such. You will find very few people who agree with >your position. I rest my case. > I rest my case. Feb 2004, "I am a relative newcomer to data management. I know what OO provides and many of its flaws. Regards Alfredo " So 18 months later you are an expert in this area? Some other interesting posts: "Why don't you write him a nice letter. Girard is one of the greates mathematicians of our time, and his contributions are widely used by computer scientists (in particular all relvant books on programming languages, formal methods and a few other domains cite his System F and the more recent contributions). What I suspect is that you don't have the necessary mathematical background to understand what he writes, otherwise you'd come up with a real argument. Trashing doesn't come close to an argument, and while Girard is justified at anytime to dismiss Alfredo Novoa's opinionated nonsense as trash , the reverse does not hold. " In fact he's carried on this view many times: "I am truly amazed about the lack of kwnolegde in this group. My query does all of that if it is required. The DBMS is for guaranteeing all the appropiate business rules, and all decent DBMSes have a security mechanism. " And never found any support for it - in fact nothing but disagreeements in the many varied forums he's brought it up in. Anyone interested in Alfredo's qualifications on this subject can go to http://groups.google.com and enter "Alfredo Novoa". These are just a few I found on the first page of results, Google appears to have a lot of them. Its also not just this topic - Alfredo has a lot of debatable views on a lot of topics and forums ranging from mathematics, to databases, to Internet Service Providers, -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs > Of course not! > > DBMS's are exactly for that. This is completely incorrect and has lead to so many bad designs. >> Of course not! >> >> DBMS's are exactly for that. > >This is completely incorrect and has lead to so many bad designs. I am sorry, but it is evident that you don't have a clue on data management theory > >> Of course not! > >> [quoted text clipped - 4 lines] > I am sorry, but it is evident that you don't have a clue on data > management theory Whatever you say. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.