Budget values

[geqmail]

I"m curious about storing budget values in a budget database. It seem
redundant to store the same value over and over again for a given
budget item (e.g., Jan=$500, Feb=$500 etc...).

For data normalization what in your experience works better? Just for
another example, could I have a value field (which may contain $500)
and another field specifying projected payouts (i.e., Annually,
MOnthly) etc?

Seems to me such a move would place greater emphasis on writing a good
query rather than storing lots of redundant data. Am I on track?

geqmail

 

[Jeff Boyce]

The data is only redundant if the budgeted amount is the same "each month".
If you don't provide the mechanism for allowing for differing amounts each
period, you'll have twice as much work.

Besides, a budgeted amount of $500 in January, 2006 and a budgeted amount of
$500 in February, 2006 are NOT redundant. Each combination is unique (and
the $$ amounts happen to match).

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[jahoobob via AccessMonster.com]

we give our salesmen monthly goal and it is the same for the whole year so I
have what we call tblBudget that has Customer and Amount. Each month this is
compared to what they actually produce. If there would be a few changed
budgets, you could create fields for each month and then enter the values for
january. You would then copy the Jan data and past it inot each of the
remaining months columns. Then edit the ones that needed to be changed.

 

[Jeff Boyce]

It sounds like you're suggesting creating a field-per-month. If so, this
works for spreadsheets, but causes serious headaches for user and Access
alike in a relational database.

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[jahoobob via AccessMonster.com]

No. I said if he has budgets that vary by the month he will have to do that
but if the monthly budget is constant throughout the year a single field will
do and that was the way we do ours. I just gave him a way to speed up the
process of entering budgets if they varied monthly.

It sounds like you're suggesting creating a field-per-month. If so, this
works for spreadsheets, but causes serious headaches for user and Access
alike in a relational database.

Regards

Jeff Boyce
Microsoft Office/Access MVP

we give our salesmen monthly goal and it is the same for the whole year so
I

[quoted text clipped - 19 lines]

 

[Guest]

I"m curious about storing budget values in a budget database. It seem

redundant to store the same value over and over again for a given
budget item (e.g., Jan=$500, Feb=$500 etc...).
For data normalization what in your experience works better? Just for
another example, could I have a value field (which may contain $500)
and another field specifying projected payouts (i.e., Annually,
MOnthly) etc?

tbl_Budgets
BudgetID (PK)
BudgetUnitID [This would be whatever units your budget is for, which could
be departments, personnel, etc. Then create a table that will have those
specified units as its records.]
FiscalYear [This forces you to review and update your budget yearly. You
could also include a quarterly field, if you need to review more often]
BudgetAmount
PayoutTimeUnit [Such as weekly, monthly, quarterly, yearly. I would suggest
that you make it a number field, and have it be the number of days between
payouts. This would allow you to do calculations in queries to automate the
whole process. Make the database do the work.]

Seems to me such a move would place greater emphasis on writing a good
query rather than storing lots of redundant data. Am I on track?

Yes. Always avoid redundant data whenever possible. If you are tempted to
use months or years as field names, then you are creating a spreadsheet.
Once you have a normalized table structure, then let the
queries/forms/reports do the work of sorting out all of the data into your
needed information packets.

 

[debra turner]

it depends on if you need to total them up later if you need to keep it
normal.
My suggestion is if you are wanting a true budget you need to be using
micrsoft excel to keep up with your budget information unless it is a huge
amount of data. you can link pages together and make charts from the data
which would be easier to manage if you have a small budget.
Don't try to make something big out of something small. Databases are for
large amounts of data to be stored and work best for that.