Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Implementing Business Logic
Business logic can be implemented in any of the three tiers of the application: front end, middle-tier components, or stored procedures. Well-written middle-tier components typically outperform the same logic implemented as stored procedures or in front-end code. Transact-SQL is a fine programming language, optimal for data retrieval and modifications. Conditional logic and heavy calculations perform better in middle-tier code.
Usually the argument arises out of the desire to control the code. DBAs are Transact-SQL code guardians, whereas developers get to maintain the middle-tier and front-end code. In addition, some SQL Server books state that even most complicated business rules can be implemented in stored procedures. Note the emphasis on the word can—this doesn't necessarily mean that stored procedures provide the best possible performance when they handle complicated logic and calculations. Yet another reason for this argument is that older, two-tiered applications employed stored procedures for all business logic. With multi-tier applications, this should no longer be the case.
As I mentioned earlier, performance tuning is typically the DBA's responsibility. Moving business logic from database code into middle-tier components should improve overall application performance. Improving application performance should be music to a good DBA's ears, so she should gladly give up the right of controlling such code.