Where Logic Lives
-
I see no reason that your example would require more than one stored procedure. You should be able to encapsulate that logic -- somehow -- so that it's data-driven (not that I'm saying that's easy!) But the database should always act as the final arbiter for data. If the database cannot validate the data (in your case, ensure that all of the proper rules were followed), the data cannot be trusted.
--
Adam Machanic
whoisactive -
Mike,
How would you define the object in the database in this case; a trade?
A "trade" would have different properties and behaviors than an equity, or an option. It may refer to an equity or an option but it is different.
"business logic" is clearly not agreed upon and needs to be broken down by the natural classifications that Adam has expressed. Also, the objects need to be clearly defined or the classification of the behaviors cannot be accomplished.
-
My example doesn't require more than one stored proc because there is no business logic in it. The model that each of those trades occurs from or because of is the business logic, not the trade itself. The trade itself is simply data. A symbol, a strike price, time of trade, time of entry, trader and that sort of stuff. The reason that all of the applications can use one stored procedure is because there is no business logic involved. That data means different things to different users/applications depending on the business logic that is applied. What you talk about is not business logic but data validation meaning in this case that you wouldn't insert a symbol with say more than 6 characters. There is a large difference between business logic and data validation.
-
Hi Peter,
Is what I stated above what you were looking for with regard to a trade
-
They're the same thing. A business rule is a data validation rule if the business is represented in the form of data.
Example: Client X has been approved for margin trading. The database ensures that no margin trades are inserted for that client. That's a business rule implemented in the database. Not that applications don't also need to implement that particular rule -- but the database makes sure that no bad data gets in.
--
Adam Machanic
whoisactive -
That's a very open definition of the data. I think that there is a risk of some other application misusing the trade table if there aren't some higher level constraints placed on inserts to the table.
If you can trust your application developers, that's great. If some of the constraints change and have to be reliably distributed out to five or more different applications and you can afford to do that, that's great.
It isn't black and white. It depends on the trust in your developers and the cost of distributing logic and constraints rather than centralizing them.
-
Do you trust the developers that will be working on the application next year?
Do you trust the outsourced developers that your company is going to hire in two years?
Do you trust that the same logic rules will be implemented the same way when the CTO decides that J2EE is really a better development platform than .NET and wants all new applications developed using it? But wants to keep supporting the old applications?
And do you trust that the logic will once again survive when those .NET applications are updated to .NEXT in 5 years time?
--
Adam Machanic
whoisactive -
Well - I trust that I've gotten the point...
what is this about trusting the developers anyway...does this mean that everything has to be designed defensively at all times ?!?! are there no "teams" and "teamwork" any more where everything is a collaborative effort of collective heads being put together ?!?!
**ASCII stupid question, get a stupid ANSI !!!** -
It's not about trusting a team, or teamwork, or anything like that.
It's about the fact that we're all human. I don't trust developers, DBAs, management, or even myself, to remember every intricacy every time anything new needs to be developed.
And that is the power of encapsulation. No need to trust anyone if you trust the code.
--
Adam Machanic
whoisactive -
Yes.
We're seeing more and more distributed teams (some without shared culture if not language), developing in Internet time, contractors that come and go.
OOD and SOA emphasize encapsulation and sharing of knowledge-etched-in-code that we can trust has been tested, won't break, and can be used from many different clients.
-
-
I would enjoy that. However, I won't be there. My current contract has me too busy, but being active in this conversation has been worth while
. Your post just beat mine in, but we are thinking alike on this.
-
well - I'm not going to PASS so i think I'll just have mine right away...
I know you're going to be one of the speakers Adam...shame I'm going to miss that and all the other names I know so well from this site and otherwise as SQL gurus!
Peter...everytime you feel a diatribe coming on...you should take deep breaths and count to 10 - 100 - whatever it takes...unless you're attending PASS and are patient enough to wait for the promised beer!
**ASCII stupid question, get a stupid ANSI !!!** -
One of the main points of my talk is to implement encapsulation and think of stored procedures as black-box APIs
--
Adam Machanic
whoisactive -
well - talk about coincidences......that alone calls for a beer!
**ASCII stupid question, get a stupid ANSI !!!**
Viewing 15 posts - 31 through 45 (of 63 total)
You must be logged in to reply to this topic. Login to reply