calculate sum for values in SQL for display per month name

Question

i have a table with the following layout.

Email Blast Table

EmailBlastId |  FrequencyId | UserId
---------------------------------
1            |   5          |   1
2            |   2          |   1
3            |   4          |   1


Frequency Table

Id | Frequency 
------------
 1 |  Daily
 2 |  Weekly
 3 |  Monthly
 4 |  Quarterly
 5 |  Bi-weekly

I need to come up with a grid display on my asp.net page as follows.

Email blasts per month.

UserId | Jan | Feb | Mar | Apr |..... Dec | Cumulative
-----------------------------------------------------
1        7      6     6     7          6     #xx

The only way I can think of doing this is as below, for each month have a case statement.

select SUM(
        CASE WHEN FrequencyId = 1 THEN 31 
        WHEN FrequencyId = 2 THEN 4
        WHEN FrequencyId = 3 THEN 1
        WHEN FrequencyId = 4 THEN 1
        WHEN FrequencyId = 5 THEN 2 END) AS Jan, 
      SUM(
        CASE WHEN FrequencyId = 1 THEN 28 (29 - leap year)
        WHEN FrequencyId = 2 THEN 4
        WHEN FrequencyId = 3 THEN 1
        WHEN FrequencyId = 4 THEN 0
        WHEN FrequencyId = 5 THEN 2 END) AS Feb, etc etc
FROM EmailBlast 
Group BY UserId

Any other better way of achieving the same?

Answer 1

You might want to consider adding a 3rd table called something like Schedule.

You could structure it like this:

MONTH_NAME
DAILY_COUNT
WEEKLY_COUNT
MONTHLY_COUNT
QUARTERLY_COUNT
BIWEEKLY_COUNT

The record for JAN would be

JAN
31
4
1
1
2

Or you could structure it like this:

MONTH_NAME 
FREQUENCY_ID 
EMAIL_COUNT

and have multiple records for each month:

JAN   1   31
JAN   2    4
JAN   3    1
JAN   4    1
JAN   5    2

I let you figure out if the logic to retrieve this is better than your CASE structure.

Answer 2

Depends on what you're looking for. Suggestion 1 would be to track your actual email blasts (with a date :-).

Without actual dates, whatever you come-up with for one month will be the same for every month.

Anyway, If you're going to generalize, then I'd suggest using something other than ints -- like maybe floats or decimals. Since your output based on the tables listed in your post can only ever approximate what actually happens (e.g., January actually has 4-1/2 weeks, not 4), you'll have a compounding error-bounds over any range of months -- getting worse, the further out you extrapolate. If you output an entire 12 months, for example, your extrapolation will under-estimate by over 4 weeks.

If you use floats or decimals, then you'll be able to come much closer to what actually happens. For starters: find a common unit of measure (I'd suggest using a "day") E.g., 1 month = 365/12 days; 1 quarter = 365/4 days; 1 2week = 14 days; etc.

If you do that -- then your user who had one 1 per quarter actually had 1 per 91.25 days; 1 per week turns into 1 per 7 days; 1 per BiWeek turns into 1 per 14 days.

**EDIT** -- Incidentally, you could store the per-day value in your reference table, so you didn't have to calculate it each time.  For example:
Frequency Table

Id | Frequency         | Value
-------------------------------
 1 |  Daily            | 1.0
 2 |  Weekly           | .14286
 3 |  Monthly          | .03288
 4 |  Quarterly        | .01096
 5 |  Once in 2 weeks  | .07143

Now do math -- (1/91.25 + 1/7 + 1/14) needs a common denom (like maybe 91.25 * 14), so it becomes (14/1277.5 + 182.5/1277.5 + 91.25/1277.5).

That adds-up to 287.75/1277.5, or .225 emails per day.

Since there are 365/12 days per month, multiple .225 * (365/12) to get 6.85 emails per month.

Your output would then look something like this:

Email blasts per month.

UserId | Jan | Feb | Mar | Apr |..... Dec | Cumulative
-----------------------------------------------------
1        6.85  6.85  6.85  6.85     6.85     #xx

The math may seem a little tedious, but once you step it out on your code, you'll never have to do it again. Your results will be more accurate (I rounded to 2 decimal places, but you could go further out if you wanted to). And if your company is using this data to determine budgets / potential income for the upcoming year, that might be worth it.

Also worth mentioning is that after YOU get done extrapolating (and the error bounds that entails), your consumers of this output will do THEIR OWN extrapolating, not on the raw data, but on your output. So it's kind of a double-whammy of error bounds. The more accurate you can be early-on, the more reliable these numbers will be at each subsequent levels.

Answer 3

Is this for any given year? I'm going to assume you want the schedule for the current year. If you want a future year you can always change the DECLARE @now to specify any future date.

"Once in 2 weeks" (usually known as "bi-weekly") doesn't fit well into monthly buckets (except for February in a non-leap year). Should that possibly be changed to "Twice a month"?

Also, why not store the coefficient in the Frequency table, adding a column called "PerMonth"? Then you only have to deal with the Daily and Quarterly cases (and is it an arbitrary choice that this will happen only in January, April, and so on?).

Assuming that some of this is flexible, here is what I would suggest, assuming this very minor change to the table schema:

USE tempdb;
GO

CREATE TABLE dbo.Frequency 
(
    Id INT PRIMARY KEY,
    Frequency VARCHAR(32),
    PerMonth TINYINT
);

CREATE TABLE dbo.EmailBlast 
(
    Id INT,
    FrequencyId INT,
    UserId INT
);

And this sample data:

INSERT dbo.Frequency(Id, Frequency, PerMonth)
  SELECT 1, 'Daily', NULL
  UNION ALL SELECT 2, 'Weekly', 4
  UNION ALL SELECT 3, 'Monthly', 1
  UNION ALL SELECT 4, 'Quarterly', NULL
  UNION ALL SELECT 5, 'Twice a month', 2;

INSERT dbo.EmailBlast(Id, FrequencyId, UserId)
  SELECT 1, 5, 1
  UNION ALL SELECT 2, 2, 1
  UNION ALL SELECT 3, 4, 1;

We can accomplish this using a very complex query (but we don't have to hard-code those month numbers):

DECLARE @now DATE = CURRENT_TIMESTAMP;
DECLARE @Jan1 DATE = DATEADD(MONTH, 1-MONTH(@now), DATEADD(DAY, 1-DAY(@now), @now));

WITH n(m) AS 
(
    SELECT TOP 12 m = number
        FROM master.dbo.spt_values
        WHERE number > 0 GROUP BY number
),
months(MNum, MName, StartDate, NumDays) AS
(    SELECT m, mn = CONVERT(CHAR(3), DATENAME(MONTH, DATEADD(MONTH, m-1, @Jan1))),
        DATEADD(MONTH, m-1, @Jan1), 
        DATEDIFF(DAY, DATEADD(MONTH, m-1, @Jan1), DATEADD(MONTH, m, @Jan1))
    FROM n
),
grp AS
(
    SELECT UserId, MName, c = SUM (
        CASE x.Id WHEN 1 THEN NumDays
            WHEN 4 THEN CASE WHEN MNum % 3 = 1 THEN 1 ELSE 0 END
            ELSE x.PerMonth END )
    FROM months CROSS JOIN (SELECT e.UserId, f.* 
        FROM EmailBlast AS e 
        INNER JOIN Frequency AS f
        ON e.FrequencyId = f.Id) AS x
    GROUP BY UserId, MName
),
cumulative(UserId, total) AS
(
    SELECT UserId, SUM(c)
      FROM grp GROUP BY UserID
),
pivoted AS
(
    SELECT * FROM (SELECT UserId, c, MName FROM grp) AS grp 
    PIVOT(MAX(c) FOR MName IN (
        [Jan],[Feb],[Mar],[Apr],[May],[Jun],[Jul],[Aug],[Sep],[Oct],[Nov],[Dec])
    ) AS pvt
)
SELECT p.*, c.total 
    FROM pivoted AS p
    LEFT OUTER JOIN cumulative AS c
    ON p.UserId = c.UserId;

Results:

UserId  Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec total
1       7   6   6   7   6   6   7   6   6   7   6   6   76

Clean up:

DROP TABLE dbo.EmailBlast, dbo.Frequency;
GO

In fact the schema change I suggested doesn't really buy you much, it just saves you two additional CASE branches inside the grp CTE. Peanuts, overall.

Answer 4

I think you're going to end up with a lot more complicated logic. Sure Jan has 31 days.. but Feb doesn't... and Feb changes depending on the year. Next, are email blasts sent even on weekends and holidays or are certain days skipped for various reasons... If that's the case then the number of business days for a given month changes each year.

Next the number of full weeks in a given month also changes year by year. What happens to those extra 4 half weeks? Do they go on the current or next month? What method are you using to determine that? For an example of how complicated this gets read: http://en.wikipedia.org/wiki/ISO_week_date Specifically the part where it talks about the first week, which actually has 9 different definitions.

I'm usually not one to say this, but you might be better off writing this with regular code instead of a sql query. Just issue a 'select * from emailblast where userid = xxx' and transform it using a variety of code methods.