|
Hello everyone,
I am designing a small budget assignment/checking application for a hierarchy organization structure. The purpose is to check and assign the budget for each employee not exceeds the total budget of a department.
The most difficult part is, a sub-department's total budget is not always lower than the upper level department's budget (i.e. the organization tree does not 100% reflects the relationship that father department node's budget is always more than that of child department node).
So, I put many exception rules to check in such situation. I am wondering whether there is any smarter ways to implement and represent the budget assignment and check model?
(I can re-write anything in this application, including data structure and algorithm, if the budget assignment and checking function is met.)
An example,
department goo under larger department foo, is represented as, /foo/goo, and /foo/zoo's budget is lower than /foo (this is a normal senses), but /foo/goo's budget is larger than /foo(this is a special rule, in the business model, even if goo under management of foo, its budget is not controlled by foo, so larger), and I maintain the remaining budget for each department,
for employee, /foo/emp1 and /foo/zoo/emp2, I can check from father node to child node for making all child nodes' budget not exceed father node, but for /foo/goo/emp3, I have to check specially. This is my headache.
If there are any smarter ways to represent the data structure and budget check, I would appreciated. 
thanks in advance,
George
|
|
|
|
|
You're working on a real project? Not just technical fun?
The world is changing...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Hi CPallini,
How do you call a real project? This is an issue I met with in a C++ project, it is not homework. A couple of guys want to make something fun and cool.
Any ideas? Smart guy?
regards,
George
|
|
|
|
|
George_George wrote: A couple of guys want to make something fun and cool
Good luck!
George_George wrote: Any ideas?
Find out yourself: having ideas is the real fun.
George_George wrote: Smart guy?
Probably you're smarter than me.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Let us wait for others' idea. My idea is too narrow.
regards,
George
|
|
|
|
|
Traditionally this sort of thing is done with tables, often database tables. You might have one table with every budget holder listed and their budget and then one or more consolidation tables expressing the budget grouping rules. Without knowing the details of what you're doing it's difficult to say exactly how it will work best. You could construct the same sort of logical structure with indexed lists or multi-dimensional arrays, sparse arrays if you've got a high dimensional data set.
One key thing in all cases is to identify a 'budget holder' as a type of entity whether that is always a person or sometimes a department or company or whatever. You'll find the coding works out much easier if it has some way of directly representing this key role. The next step might be to identify the set of relationship between budget holders in your complex hierarchy and then try to represent each of those relationships unambigously either as a type or in terms of a data structure.
Don't be afraid to tear up the design and start agiain a few times. I'm sure you'll soon have an efficient mapping from the real world onto a C++ class structure and back again. Good luck
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks Matthew,
Do you mean using one table to store budget holder information, and mapping the related budget grouping rules to the budget holders, using data structures like indexed lists or multi-dimensional arrays, sparse arrays?
regards,
George
|
|
|
|
|
That's certainly one way you could do it.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks Matthew,
Your insights give me more ideas. Now I make the algorithm in details and want to let you review and
comment. Sorry, I do not adope 100% of your ideas.
1. Any node can have multiple childs, for example, foo has goo and zoo as two childs;
2. If each child has its special money management system, I will put a special pointer to the money object, or else, it will share the same money source from parent (its money pointer points to the same money object of that of parent);
3. In the money object, it contains the pool of nodes which gets money from the object and how much each node gets from the money object, from total amount of money of the money object, and the consumed money by all the nodes, we can make sure how much remains;
4. When checking/assigning remaining budget for a specific child, traverse from the parent (root) of the tree to the specific child, and check its "money pointer" to see the remaining amount of money.
regards,
George
|
|
|
|
|
It sounds like it would work. It also sounds potentially complex so if it was me then one or more diagrams might be needed just to make sure.
When it comes to cleaning up the data structure it's important to be able to visit every node exactly once in order to delete them and not 'orphan' any nodes by deleting everything that refers to them before they're deleted or worse still try to delete something twice! If you can avoid that sort of problem I reckon you'll be fine. Don't forget to post an article when it's done
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks Matthew,
Matthew Faithfull wrote: in order to delete them
I do not understand why I need to delete anything in my described algorithm before?
regards,
George
|
|
|
|
|
Everything has to be deleted eventually. I assume you're not allocating all these structures on the stack so you're eventually going to have to delete them. 'Linear Traversabiliy', being able to iterate through every node and reach each one exactly once, is a very important property to maintain in complex data structures. Deleting a non linear-traversable data structure reliably is potentially very nasty. Don't go there. Keep it as simple as it can be to do the job and it'll be fine.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks Matthew,
1.
Do you mean each time, I establish the structure, and after each check/assignment, I delete the structure?
2.
Why I need to delete the structure? The structure remains the same, I just need to change the budget amount with budget assignment operation.
regards,
George
|
|
|
|
|
George_George wrote: 1.
Do you mean each time, I establish the structure, and after each check/assignment, I delete the structure?
No
George_George wrote: 2.
Why I need to delete the structure? The structure remains the same
Every piece of software must be shutdown eventually. A clean shutdown is important.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Sorry I misunderstand your points before. You mean release the resource (e.g. memory) occupied by the tree structure, right?
regards,
George
|
|
|
|
|
Me think your design is flawed, your busines rules are flawed.
Each department will need to have a "budget controling" parent; so effectivally, the "budget controling" parent will also be the organisational parent.
if goo's budget is not controled by foo it must be controled by another departement; and in any organisations, if that was the case, then goo will not be under foo.
Remember that each time you start adding exceptions to a design, you increase the instability of said design, and it will make it virtually impossible to code and test and maintain later on in a project lifetime.
I'm certain there are smarter people who will find a gooder solution.
|
|
|
|
|
Hi Maximilien,
Your comments are great!
I can not change,
1. the business rules;
2. the organization of departments.
I can change, any data structures, like how to represent budget/organization relationship. Do you have any smarter solutions?
regards,
George
|
|
|
|
|
Maximilien wrote: Each department will need to have a "budget controling" parent; so effectivally, the "budget controling" parent will also be the organisational parent.
if goo's budget is not controled by foo it must be controled by another departement; and in any organisations, if that was the case, then goo will not be under foo.
A Department can get its budget from any number of "budget-givers". But it can only have exactly one organisational parent I cant imagine otherwise.
George_George, you probably need to separate budget and organisation and build two hierarchies.
Probably quite early in the design, you will need a tool to graphically depict the relationships in your database.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
int compute(int n)
{
if(n>0)
{
n=compute(n-3)+compute(n-1)
return n;
}
return 1;
}
void main()
{
x=compute(5);
cout<<x;
}
o/p:9 can anybody explain in detail the flow
|
|
|
|
|
I can tell you why it doesn't work: it goes into infinite recursion.
I was wrong.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
modified on Friday, April 18, 2008 10:19 AM
|
|
|
|
|
CPallini wrote: it goes into infinite recursion.
While I don't know exactly what it computes, it does indeed terminate.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Yes, it is true, I was wrong.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
sorry i am late
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
it working fine for me.. it not going in infinite recursion!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
