|
The required logic depends on a number of variables,
many of which were not mentioned in the question. Imagine a
table of data that looks like this:
JAN 125
FEB 95
MAR 210
APR 305
MAY 405
JUN 295
JUL 80
AUG 95
SEP 510
OCT 230
NOV 245
DEC 450
Okay, maybe there isn't an actual 12-row table with two columns
sitting out there in your database. Doesn't matter. A simple query
with a GROUP BY on the monthname and a SUM expression for the amount
will produce a result set which is just another name
for a table.
So one way to look at the requirement is that if you
pass 'APR' to the function, you want 610 returned.
But what happens in JAN? Do you really want to use DEC?
How do you know which year it is?
Actually, that's not such an absurd thought. Suppose
these were AVGs, instead of SUMs. Representing, oh, for example,
average rainfall in litres per football field. Then pulling
NOV,DEC,JAN when passed JAN makes perfect sense, because that
data does wrap around, just like the months do.
You were kind enough to ask for ideas, and my best suggestion
is to pass in the year as well as the month—when it makes
a difference.
|
