I have three columns (CWOC, C, and PWC). both CWOC and PWC are dependent on the value in C, yet C is dependent on the value in PWC.
Basically:
C = PWC * BR
PWC = MR - CWOC
CWOC = MC - C
In setting up these columns in the database how do I set up columns like these that are so dependent on each other?
This was set up previously in Excel using iteration, but now I'm recreating the application in VB.net and SQL Server.
Thanks for your suggestions.There is no single logical solution to that set of equations. There are, in fact, infinite stable solutions. So how are you going to select one? And what good is it? Is this some sort of fractal database or chaos theory experiment?|||That's just how the client calculates their commissions.|||Oh.
My.
God.
I once had the task of setting up a commision and compensation system for territory sales reps. The Regional Director wanted something simple and understandable. So I gave them something simple and understandable. Then they wanted it to consider existing market saturation in each territory, so I threw in weighted averaging. Then they wanted it to account for seasonal variations, so I added an exponential smoothing model to the algorithm. Then they wanted it to account for historical performance, so I included a linear regression model in the algorithm.
You guessed it. None of the sales reps would accept the compensation model because it was too complicated. They would rather have something that was less than fully fair which they could calculate on their own, and I understood their point.
So how in the world did they end up with a non-linear commision structure?
I'm not just asking to be nosy, or out of incredulousness (ok, a bit of that...). But if you explain a bit more about the algorithm MAYBE I can help you come up with something...|||I give you my 2 cents opinion.
I put everything is under the hat of "business logic" in a stored procedure (with the aid of UDF if needed) or into an intermediate COM+ component. In this case, since the logic must be applied to the data contained in the database itself, i'd prefer the stored procedure solution.
This won't dirty your database design with business logic implication, so that in the future, if the business logic change it won't be necessary to change the db schema and vice-versa.
No comments:
Post a Comment