February 8, 2017 at 9:10 am
Steve Thompson-454462 - Wednesday, February 8, 2017 8:30 AMI'd throw in my vote for not loading up stored procs with business rules. Full disclosure: I have personally loaded up SPs with business logic many, many times and always with open eyes. It's just that, IMO, this counts as technical debt since in many organizations the data layer has the least transparency and it's generally preferable to have the implementation of business rules transparent to the business. When possible, having the business own the business rule implementation using a BRE (and exposing this to client apps via a service) provides the maximum transparency, but not all organizations are in a position to handle it this way (mine is just starting to refactor around this model).
Does the part that I set as bold means that organizations don't have people that understand SQL? Or what do you mean by transparency? Everything should be documented either way.
February 8, 2017 at 9:17 am
Luis Cazares - Wednesday, February 8, 2017 9:10 AMSteve Thompson-454462 - Wednesday, February 8, 2017 8:30 AMI'd throw in my vote for not loading up stored procs with business rules. Full disclosure: I have personally loaded up SPs with business logic many, many times and always with open eyes. It's just that, IMO, this counts as technical debt since in many organizations the data layer has the least transparency and it's generally preferable to have the implementation of business rules transparent to the business. When possible, having the business own the business rule implementation using a BRE (and exposing this to client apps via a service) provides the maximum transparency, but not all organizations are in a position to handle it this way (mine is just starting to refactor around this model).Does the part that I set as bold means that organizations don't have people that understand SQL? Or what do you mean by transparency? Everything should be documented either way.
He he, my guess is that some data magically appears in some tables and no one really knows how it gets there.
😎
February 8, 2017 at 9:22 am
Luis Cazares - Wednesday, February 8, 2017 9:10 AMSteve Thompson-454462 - Wednesday, February 8, 2017 8:30 AMI'd throw in my vote for not loading up stored procs with business rules. Full disclosure: I have personally loaded up SPs with business logic many, many times and always with open eyes. It's just that, IMO, this counts as technical debt since in many organizations the data layer has the least transparency and it's generally preferable to have the implementation of business rules transparent to the business. When possible, having the business own the business rule implementation using a BRE (and exposing this to client apps via a service) provides the maximum transparency, but not all organizations are in a position to handle it this way (mine is just starting to refactor around this model).Does the part that I set as bold means that organizations don't have people that understand SQL? Or what do you mean by transparency? Everything should be documented either way.
Not that they don't understand SQL, Luis. Maybe you could make an argument that a business rule expressed as SQL may be further removed from "natural" language than one written in, say, Java (though I'm more than willing to accept that this point is moot); in either case the requirement to providing transparency shouldn't be solved by forcing the BA's to learn a specific language. I think I'm trying to say something more like it's level of embedding puts it farther removed from the business user. I do think you make an excellent point that was certainly true in my case: lack of documentation creates more problems than the method of implementation.
February 8, 2017 at 9:24 am
Eirikur Eiriksson - Wednesday, February 8, 2017 9:17 AMLuis Cazares - Wednesday, February 8, 2017 9:10 AMSteve Thompson-454462 - Wednesday, February 8, 2017 8:30 AMI'd throw in my vote for not loading up stored procs with business rules. Full disclosure: I have personally loaded up SPs with business logic many, many times and always with open eyes. It's just that, IMO, this counts as technical debt since in many organizations the data layer has the least transparency and it's generally preferable to have the implementation of business rules transparent to the business. When possible, having the business own the business rule implementation using a BRE (and exposing this to client apps via a service) provides the maximum transparency, but not all organizations are in a position to handle it this way (mine is just starting to refactor around this model).Does the part that I set as bold means that organizations don't have people that understand SQL? Or what do you mean by transparency? Everything should be documented either way.
He he, my guess is that some data magically appears in some tables and no one really knows how it gets there.
😎
That's not a bad example at all.😛
February 8, 2017 at 9:59 am
Steve Thompson-454462 - Wednesday, February 8, 2017 9:24 AMEirikur Eiriksson - Wednesday, February 8, 2017 9:17 AMLuis Cazares - Wednesday, February 8, 2017 9:10 AMSteve Thompson-454462 - Wednesday, February 8, 2017 8:30 AMI'd throw in my vote for not loading up stored procs with business rules. Full disclosure: I have personally loaded up SPs with business logic many, many times and always with open eyes. It's just that, IMO, this counts as technical debt since in many organizations the data layer has the least transparency and it's generally preferable to have the implementation of business rules transparent to the business. When possible, having the business own the business rule implementation using a BRE (and exposing this to client apps via a service) provides the maximum transparency, but not all organizations are in a position to handle it this way (mine is just starting to refactor around this model).Does the part that I set as bold means that organizations don't have people that understand SQL? Or what do you mean by transparency? Everything should be documented either way.
He he, my guess is that some data magically appears in some tables and no one really knows how it gets there.
😎That's not a bad example at all.😛
I believe it really comes down to the simple statement "It depends." How many different ways are there to access the data (insert, update, delete). If you can guarantee that one and only one application can ever access the database to accomplish inserts, updates, and deletes then I may agree that business logic may not be appropriate in the database. The problem is that this is not true, and I firmly believe that a well designed database can protect itself and the business. This means you probably should place enough of the business logic in the database to protect the data and reduce the number of places business logic needs to be modified when changes are required. If you have to make changes in multiple applications and interfaces to accomplish a change there is always the possibility of missing or incorrectly making a change during the process. This maybe more likely to happen with there are multiple applications written in several different languages or disparate groups.
February 8, 2017 at 10:30 am
Lynn Pettis - Wednesday, February 8, 2017 9:59 AMSteve Thompson-454462 - Wednesday, February 8, 2017 9:24 AMEirikur Eiriksson - Wednesday, February 8, 2017 9:17 AMLuis Cazares - Wednesday, February 8, 2017 9:10 AMSteve Thompson-454462 - Wednesday, February 8, 2017 8:30 AMI'd throw in my vote for not loading up stored procs with business rules. Full disclosure: I have personally loaded up SPs with business logic many, many times and always with open eyes. It's just that, IMO, this counts as technical debt since in many organizations the data layer has the least transparency and it's generally preferable to have the implementation of business rules transparent to the business. When possible, having the business own the business rule implementation using a BRE (and exposing this to client apps via a service) provides the maximum transparency, but not all organizations are in a position to handle it this way (mine is just starting to refactor around this model).Does the part that I set as bold means that organizations don't have people that understand SQL? Or what do you mean by transparency? Everything should be documented either way.
He he, my guess is that some data magically appears in some tables and no one really knows how it gets there.
😎That's not a bad example at all.😛
I believe it really comes down to the simple statement "It depends." How many different ways are there to access the data (insert, update, delete). If you can guarantee that one and only one application can ever access the database to accomplish inserts, updates, and deletes then I may agree that business logic may not be appropriate in the database. The problem is that this is not true, and I firmly believe that a well designed database can protect itself and the business. This means you probably should place enough of the business logic in the database to protect the data and reduce the number of places business logic needs to be modified when changes are required. If you have to make changes in multiple applications and interfaces to accomplish a change there is always the possibility of missing or incorrectly making a change during the process. This maybe more likely to happen with there are multiple applications written in several different languages or disparate groups.
Lynn, agreed that single point of encapsulation is valuable. Also agreed on the "it depends"; I think the major thing it depends on is architecture. In a monolithic architecture with a shared database the technical debt will be much less than in any flavor of service-based architecture, where shared dbs can be a bit of an anti-pattern. If you're looking to break up your monolith into micro-services, say, then having business rules embedded in the data layer will add to the scope of the refactor. In designing such a system, a single repository of all business logic fights against the notion of bounded contexts. So I'm not sure I agree that an increase in the number of applications (or tools, or services, etc.) interfacing with your domains makes the monolith more attractive; rather such a system would likely benefit from services with properly bounded domain contexts. I suppose you could argue that schemas in the data layer can provide some of the logical function of bounded contexts, but they don't really help when it comes to devops issues like deploying, scaling. etc.
February 9, 2017 at 9:30 am
Luis Cazares - Friday, February 3, 2017 1:07 PMPeople mention portability of code and correct placement of business rules as disadvantages of Stored Procedures.
I've seen far more times systems changing their front end code language than their database systems (not counting upgrades).What I've seen published as disadvantages are more likely ignorance from people writing them.
Hear hear.
Ben
(The number of RDBMSses is Faaar less than the number of development environments that use RDBMSses).
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply