Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
In a previous post I wrote about using a few tables to capture information about my solar system. With a way to capture the data for each day, I now want to report on this. This post will look at the first part of my reporting, which is the daily reporting.
Scenario
On a daily basis, I want to know if the system is producing more or less than the estimate for that month. If you remember from the previous post, there is a single row in a table for each month and then a row in a different table for each day.
My estimates look like this:
Each day looks like:
What I want is a comparison of the actual output against the estimate for each day that I have data. I don’t want to see a number of zeros unless the system produced no power. What I really want is the estimate expanded to cover each of the days of the month for which I have actual data. I want to see this:
A Simple Join
This is very simple query to write. It’s really a join between the two tables, based on the month. If I join on month, then the data from the estimate is returned for each row of actual data where the month’s match.
I can then assemble the date in the results using DATEFROMPARTS(). When I do that, I have this code:
SELECT
DATEFROMPARTS (spa.trackingyear, spa.trackingmonth, spa.trackingday) AS ProductionDate
, spa.actual_daily AS Actual
, spe.estimate_daily AS Estimate
FROM
dbo.SolarPowerActual AS spa
INNER JOIN dbo.SolarPowerEstimate AS spe
ON spe.trackingmonth = spa.trackingmonth
ORDER BY ProductionDate
This gives me the results I need, and it works well. Since I have numeric values for the months in both tables, this is a very quick join, especially when those columns are indexed. In this case, most of the time the index won’t matter as we really are pulling most of the data from one table and the tables are so narrow that the index might not ever help.
I’ll compile this code into a view, which I can use for more detailed analysis.
SQL New Blogger
I was building this system to track some data, and decided to split up each section into a separate post. If you look at the first post and this one, you will see they are both short and could be combined, but I wanted to separate them into different topics, as well as schedule them separately.
A good technique you can use on your blog to separate out topics and ensure a more consistent pipeline of content as you publish information about you knowledge.
Voice of the DBA 