Comments posted to this topic are about the item The Scariest Data Type
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
The scariest data type may be sql_variant, but any data type can made to be scary if it is nullable.
The scariest data type?...
Creator of SQLFacts, a free suite of tools for SQL Server database professionals.
I do not see anything scary about NULLs as UNKNOWN is a perfectly good answer.
Just to add to this... I've found that the absolute scariest datatype is when people use the wrong datatype to store data, no matter what it is.
My recent favorite examples are VARCHAR(1) for anything, Dates and Times being stored as any non-temporal datatype, anytime people blindly convert DATETIME2() or TIME() to DATETIME, and VARCHAR() based CreatedBy and ModifiedBY columns. It's not just "ExpAnsive" updates that occur on ModifiedBy columns... for example, you have numerous NULLable VARCHARs in a table. If you store just 1 character in the CreatedBy column, which is usually one of the right-most columns in a table, do you have any idea how many bytes of storage that will really consume. I'll give you a hint... it's a hell of a lot more that 1 byte for the character and 2 bytes for the starting position of the data in the row. 😀
I also find that the use of any of the "newer" temporal datatypes are a PITA because you cannot do direct date math with them like you can with the DATETIME datatype (for example, for calculating duration or adding duration to a start date/time to predict and end date/time). If MS had the foresight to create a DATEADD_BIG() when they created DATEDIFF_BIG(), there wouldn't be such issues. They still haven't created DATEADD_BIG() even in 2022.
Change is inevitable... Change for the better is not.
Viewing 5 posts - 1 through 4 (of 4 total)