Data Typing Quandry

  • Robert Davis

    One Orange Chip

    Points: 28027

    Comments posted to this topic are about the item Data Typing Quandry


    My blog: SQL Soldier[/url]
    SQL Server Best Practices:
    SQL Server Best Practices
    Twitter: @SQLSoldier
    My book: Pro SQL Server 2008 Mirroring[/url]
    Microsoft Certified Master: SQL Server, Data Platform MVP
    Database Engineer at BlueMountain Capital Management[/url]

  • Hardy21

    SSCrazy Eights

    Points: 9708

    Very nice question though I got it wrong.

    I was thinking because of only 3 bit column, it should take 1 byte only same as tinyint.

    Thanks

  • Nakul Vachhrajani

    SSChampion

    Points: 10197

    Really very nice question. Gets the mind thinking about the internal storage and is a very, very important consideration for capacity planning.

    I got it right, but I must admit that it was only because of two points:

    1. I am currently trying to understand database compression

    2. I just read about this in Books On Line (It's hardly been two days!)

    Great question, great discussion sure to follow! I am looking forward to following the entire thread.

    Have a wonderful rest-of-the-day!

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com
    Be courteous. Drive responsibly.

    Follow me on
    Twitter: @sqltwins

  • Iulian -207023

    SSCertifiable

    Points: 7509

    Great question, thank you.

    I answered wrong by assuming there is no place for compressing bit fields more than it already does, in this case to one byte, I should have thought about the header.

    Have a great day,

    Iulian

  • Jinx-640161

    Ten Centuries

    Points: 1108

    Good question, thanks.

  • Richard Warr

    SSCertifiable

    Points: 6957

    Nice question - I thought they would all be the same size as well.

    _____________________________________________________________________
    MCSA SQL Server 2012

  • malleswarareddy_m

    SSCertifiable

    Points: 5847

    Great Question.Keep continue Posting.

    Malleswarareddy
    I.T.Analyst
    MCITP(70-451)

  • Michael Riemer

    SSCertifiable

    Points: 5048

    Great question and interesting - Learnt something new today. Thought I understood compression but need to look into it a bit more it seems!

  • RichardDouglas

    SSCarpal Tunnel

    Points: 4029

    Interesting, I knew there was an overhead to data compression but went for TinyInt over Bit.

    Good question, thanks for taking the time to help educate the SQL community.

    Hope this helps,
    Rich

    [p]
    [/p]

  • sjimmo

    SSChampion

    Points: 11139

    Excellent question - got it wrong but learned something new. It's going to be a great day:hehe:

    Steve Jimmo
    Sr DBA
    “If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan

  • SanDroid

    SSChampion

    Points: 10068

    Disapointing and Lame trick question.

    The question asked which row had the "largest defined row size", not "the largest storage size".

    The answer in the the reference material is for a differant question.

    Storage size and defined size are two differant concepts.

    The following quote is from the books online section on how to choose between ROW and PAGE compression.

    Compression can allow more rows to be stored on a page, but does not change the maximum row size of a table or index.

    http://msdn.microsoft.com/en-us/library/cc280449.aspx

    So even though the maximum storage size of the data is less with compression on, the defined maximum row size of the data is not any differant.

  • cy-dba

    SSCarpal Tunnel

    Points: 4149

    SanDroid (11/17/2010)


    Disapointing and Lame trick question.

    The question asked which row had the "largest defined row size", not "the largest storage size".

    The answer in the the reference material is for a differant question.

    Storage size and defined size are two differant concepts.

    The following quote is from the books online section on how to choose between ROW and PAGE compression.

    Compression can allow more rows to be stored on a page, but does not change the maximum row size of a table or index.

    http://msdn.microsoft.com/en-us/library/cc280449.aspx

    So even though the maximum storage size of the data is less with compression on, the defined maximum row size of the data is not any differant.

    I was thinking along the same path, although I thought it still was a good question because I did learn something new.

  • SanDroid

    SSChampion

    Points: 10068

    chrs-513176 (11/17/2010)


    I was thinking along the same path, although I thought it still was a good question because I did learn something new.

    I had already learned the differance between Defined Row size and Storage Row size during my upgrading SQL server skills course.

    The differance actually saved us from purchasing a recomended unecessary upgrade for a location.

    They were having issues with maxing out the Network during the transfer of a large table that was filled with a lot of un-normalized data. Since the bottle-neck was not in the Disk-IO or the amount of storage being used compression would not have helped. Instead we normalized the data that was being requested from ten large tables joined by an excel formula to one table of just the data being requested using a view.

    Creating the view cost less than SQL 2008 Enterprise.

  • mtassin

    SSC-Insane

    Points: 23096

    SanDroid (11/17/2010)


    Disapointing and Lame trick question.

    The question asked which row had the "largest defined row size", not "the largest storage size".

    Compression can allow more rows to be stored on a page, but does not change the maximum row size of a table or index.

    http://msdn.microsoft.com/en-us/library/cc280449.aspx

    So even though the maximum storage size of the data is less with compression on, the defined maximum row size of the data is not any differant.

    I agree. I got this wrong for the same reason. The Row Size doesn't change, compression just lets more data be stored on a page.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • UMG Developer

    SSChampion

    Points: 13482

    mtassin (11/17/2010)


    I agree. I got this wrong for the same reason. The Row Size doesn't change, compression just lets more data be stored on a page.

    But in this case compression actually makes it so less data fits on a page because of the metadata overhead.

Viewing 15 posts - 1 through 15 (of 37 total)

You must be logged in to reply to this topic. Login to reply