Tag: T-SQL

  • Limiting the Max–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I was chatting with someone the other day about MAX() and how it can work within a set of rows, rather than across an entire result set. That’s a good query skill to have, so I mocked up a short demo. This will show the window functions in T-SQL, using the OVER() clause with MAX.

    Let’s build a table and add some data.

    CREATE TABLE counters
    ( countid INT IDENTITY(1,1)
    , countername VARCHAR(20)
    , counteryear INT
    , mycounter INT
    )
    GO
    INSERT dbo.counters
            ( countername
            , counteryear
            , mycounter
            )
        VALUES
            ( 'Test1', 2012, 1 ),
            ( 'Test1', 2013, 2 ),
            ( 'Test1', 2014, 3 ),
            ( 'Test1', 2015, 4 ),
            ( 'Test1', 2016, 5 ),
            ( 'Test1', 2017, 6 )
    GO

    If I now query, I will just use and ORDER BY clause in the OVER() clause. This will order all the rows from the result set by the year, and then apply a MAX to them.

    SELECT
        countid,
        countername,
        counteryear,
        mycounter,
        sumofallvalues = SUM(mycounter) OVER (ORDER BY counteryear),
        maxcounter = MAX(mycounter) OVER (ORDER BY counteryear)
    FROM dbo.counters
    ORDER BY
        countername,
        counteryear;
    

    The partial results are shown below. The important parts are the year and the sum/max values.
    2017-04-18 06_47_36-SQLQuery3.sql - (local)_SQL2016.NBA (PLATO_Steve (71))_ - Microsoft SQL Server M

    We see here that the counter increases by one until the last row. This is the data set, the year and counter increment. The max should be six, but it’s not six until the last row. Why?

    The answer comes from the framing of the rows. The OVER() clause, by default use a range of unbounded preceeding and current row as it’s set of values. In this case, with an order by on the counteryear, this means that when the query engine processes the first row, the entire set of values in the window is just the row with 2012. The next row has two rows, with unbounded preceeding being 2012 and the current row of 2013. This means for each set of rows, the range consists of previous values. I’ll show here what the counteryear values are for each row and the result of the max:

    • 2012 uses the 2012 row only – max 1
    • 2013 uses the 2012 and 2013 rows – max 2
    • 2014 uses the 2012, 2013, and 2014 rows – max 3
    • 2015 uses the 2012, 2013, 2014, 2015 rows – max 4
    • 2016 uses the 2012, 2013, 2014, 2015, 2016 rows – max 5
    • 2017 uses the 2012, 2013, 2014, 2015, 2016 rows – max 6

    This is a window that moves with the data, and is defined as being from the beginning of the result set to the current row.

    Let’s change things. I’ll add a second set of rows, and we can see here how this might differ.

    INSERT dbo.counters
     ( countername
     , counteryear
     , mycounter
     )
     VALUES
     ( 'Test2', 2012, 1 ),
     ( 'Test2', 2013, 4 ),
     ( 'Test2', 2014, 2 ),
     ( 'Test2', 2015, 8 ),
     ( 'Test2', 2016, 5 ),
     ( 'Test1', 2017, 11 )
     GO

    Now, let’s query again, but we’ll change our window. First, we’ll order by name for the MAX(), since that’s what we want to show. I’ll leave SUM alone. Next, I’ll change the window to be only the previous row and the current row.

    SELECT
     countid,
     countername,
     counteryear,
     mycounter,
     sumofallvalues = SUM(mycounter) OVER (ORDER BY counteryear),
     maxcounter = MAX(mycounter) OVER (PARTITION BY countername
     ORDER BY counteryear
     ROWS BETWEEN 1 PRECEDING AND CURRENT ROW
     )
     FROM dbo.counters
     ORDER BY
     countername,
     counteryear;

    Now the results are a bit different. My final ORDER BY ensures I have the tests separated. The first one looks similar in the max columns. I’ll explain the SUM in a different post.

    2017-04-18 06_55_24-SQLQuery3.sql - (local)_SQL2016.NBA (PLATO_Steve (71))_ - Microsoft SQL Server M

    The MAX() for test2 is different. Let’s see what happens here. Since my window is a ROWS clause, and it’s set for 1 preceeding and the current row, I get these values.

    Test2, 2012 row

    • Preceeding  – no values
    • Current – 1
    • Max – 1

    Test2, 2013 row

    • Preceeding  – 1 (2012 value)
    • Current – 4
    • Max – 4

    Test2, 2013 row

    • Preceeding  – 4 (2013 row)
    • Current – 2
    • Max – 4

    Test2, 2014 row

    • Preceeding  – 2
    • Current – 8
    • Max – 8

    Test2, 2015 row

    • Preceeding  – 8
    • Current – 5
    • Max – 8

    This shows that MAX  is limited to the frame I’ve applied to the window. The window is the OVER() clause, which in this case is the set of rows with the same counteryear value (the partition).

    Window functions get confusing and are strange, especially if you’ve spent most of your career without them and finding tricks to use COUNT(), SUM(), and other aggregates on subsets of rows. Things get easier in SQL Server 2012+, and you should spend time playing with small sets of data and understanding windows.

    SQLNewBlogger

    This was about a 15-20 exercise, but it was good since I needed to stop and think about how to use and show a window function and the ranges. Good skills practice.

    I’d like to see others explain this with a data set that they find interesting.

    References

    OVER() – https://docs.microsoft.com/en-us/sql/t-sql/queries/select-over-clause-transact-sql

    MAX() – https://docs.microsoft.com/en-us/sql/t-sql/functions/max-transact-sql

  • Watch Your DataTypes in Aggregates–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I’ve got a database of NBA statistics with data like this for players. I downloaded a CSV and loaded it into SQL Server.

    2017-03-22 10_32_00-SQLQuery1.sql - (local)_SQL2016.NBA (PLATO_Steve (102))_ - Microsoft SQL Server

    I decided to play with the data a bit and at one point wanted to see who scored the most points for a team and year. So I ran this query:

    SELECT
        year,
        team,
        MAX(pts)
    FROM dbo.player_regular_season
    WHERE
        year = ‘1972’
        AND team = ‘LAL’
    GROUP BY
        year,
        team;

    The result was 705. That’s a decent number of points, and if I weren’t careful, this might seem fine. 1972 was a long time ago, and they didn’t score as many points as they do today in games.

    In fact, if I were putting this in a summary report with lots of data, it might be the case that someone glancing at this would make a poor decision based on the data.

    Why?

    Let’s look at the data.

    2017-03-22 10_46_16-SQLQuery1.sql - (local)_SQL2016.NBA (PLATO_Steve (102))_ - Microsoft SQL Server

    Even a quick glance would let me know this seems funny. There are values of 1575 and 1084 in there, but the MAX() I returned was 705. If I look deeper at the import, I can see why.

    2017-03-22 10_47_25-SQLQuery1.sql - (local)_SQL2016.NBA (PLATO_Steve (102))_ - Microsoft SQL Server

    Anything stand out there? If you look, pts is a varchar, not a numerical value. In the character world, 705 beats 1575. I really need this query:

    2017-03-22 10_48_30-SQLQuery1.sql - (local)_SQL2016.NBA (PLATO_Steve (102))_ - Microsoft SQL Server

    Always be aware of the datatypes you work with and manipulate. Knowing a little bit about the meaning and use of the data can help you spot anomalies like this. As much as I like random test data, I’d also be sure you have some real data cases when you have users check your work. It’s easy for them to miss problems like this without good reference cases.

    Or use good test data that you’ve setup and unit tests.

  • Implicit Time Conversions – #SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I was trying to work with times recently and needed to get the current time. I thought, well, Getdate(), or better yet, SysDateTime() will give me a date and time, but what about the time?

    A simple experiment showed it’s easy:

    DECLARE
        @t TIME,
        @t1 TIME;
    SELECT @t = SYSDATETIME(), @t1 = GETDATE();
    SELECT @t, @t1;

    I got this:

    2017-02-24 12_34_19-SQLQuery2.sql - (local)_SQL2016.PartsUnlimited_Grant (PLATO_Steve (59))_ - Micro

    Quick, easy, and what I suspected would work. If you need to work with times, you can easily cast a datetime value to a TIME to strip the date, or just assign the values to a time.

    CREATE TABLE TimeTest
    (t TIME)
    GO
    INSERT TimeTest
    SELECT top 10
     CreationDate
     FROM dbo.Posts
     GO
     SELECT top 10
      *
      FROM dbo.TimeTest
    GO
    DROP TABLE TimeTest

    This code takes a datetime column and just inserts the time into the new table.

    SQLNewBlogger

    Literally about 3 minutes of my day to write this. When you learn something, write it down.

  • Writing the Correct Query is Important

    There’s a saying in the data world: garbage in, garbage out. We use that when we can’t get good information from our database because the data we’ve stored isn’t as useful as we would like. That’s a problem, and it’s one reason why data professionals want to spend time thinking about the data we need to collect and how to store it. We want to be sure that we’ve at least made an effort to collect useful data that someone will use.

    We sometimes have the data we need, but still struggle to use it effectively. I think this is an area where machine learning and similar technologies may help in the future, but there is a lot of work to be done to allow most of us to take advantage of those tools. In the meantime, many of us make do with basic T-SQL to perform data analysis, generate reports, and provide the answers to questions. When we do so, it’s important that our queries actually work correctly to answer the questions we need.

    I don’t want this to be a political discussion, and I would appreciate that any comments be limited to the technical subject. I ran across a piece about a failure of the US government in determining the status of people being checked for immigration status. The interesting quote in this article was “… officials blamed computer code for the problem.” Leaving aside the implications in this case, the idea that computer code, likely some sort of query code, is not working as expected, querying the correct data, or isn’t being used properly is disturbing.

    I’ve run across quite a few stories like this from various consultants that were called in to help organizations, only to find out the queries that had been used for long periods of time were incorrect. They didn’t filter appropriately, didn’t convert or aggregate data as intended, or didn’t even query the correct data.

    We use databases and queries extensively in today’s world, and the growth is only going to increase. As much as I like the idea of DevOps and more frequent deployments, I also want higher quality for our software. This means that we need to ensure that our queries actually work as intended against databases. Code reviews, independent checks, using known data sets that evolve and include edge cases of data are all ways we can work to ensure we are actually writing the correct queries for our data. Above all, we need to be sure we are using test of some sort, preferably unit tests, that ensure the queries are actually the ones we want.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.8MB) podcast or subscribe to the feed at iTunes and Libsyn.