Home Forums SQL Server 2012 SQL Server 2012 - T-SQL trimming SSNs RE: trimming SSNs

  • March 15, 2019 at 9:04 am

    #2024584

    jcelko212 32090 - Thursday, March 14, 2019 8:19 PM

    ScottPletcher - Thursday, March 14, 2019 3:01 PM

    jcelko212 32090 - Thursday, March 14, 2019 1:44 PM

    briancampbellmcad - Wednesday, March 13, 2019 9:50 AM

    I see no reason at all to waste 2 bytes per row storing dashes.  2B rows = 4B bytes totally wasted.

    Are these the same two bytes we saved by dropping the century from dates back in the Y2K days?  I'm going to argue for the dashes. The design principle that you want to store data the way it is used and use it the way it's stored. When you see 2019-03-19, you know that it's a date. When you see 252-77-6688, you know that it's a Social Security number. Likewise, 23:00:00 Hrs is clearly a time. The cost of a couple of pieces of punctuation is negligible these days, but the cost of an error in misreading the data is not negligible.

    So you're saying that we should store dates as '2019-03-19'?  That's just not done.  Do we need to store the blanks in credit card #s too, which are usually printed on cards as nnnn nnnn nnnn nnnn to make them easier to read.

    The display has nothing to do with how data is stored.

    The Y2K method only saved one byte, and, yes, it was the correct decision at the time.

    You love living in a completely theoretical world, where the logical design is never converted to physical design.  Back in the real world, we have to follow the normal process of converting a logical design to a physical one, accepting comprises along the way.

    SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.