Data Typing Quandry
-
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] -
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
-
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.comFollow me on
Twitter: @sqltwins -
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
-
Good question, thanks.
-
Nice question - I thought they would all be the same size as well.
-
Great Question.Keep continue Posting.
Malleswarareddy
I.T.Analyst
MCITP(70-451) -
Great question and interesting - Learnt something new today. Thought I understood compression but need to look into it a bit more it seems!
-
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] -
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 -
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.
-
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.
-
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.
-
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] -
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 36 total)
You must be logged in to reply to this topic. Login to reply