• Dennis (unregistered)

    Storing customer IDs as number types is not just "not ideal", it is WRONG, TRWTF, and the source of all these issues.

    I'd like to hate on Microsoft, but this is not their fault.

  • Dennis (unregistered) in reply to Dennis

    Oh, and "I like to prefix" is also just wrong. Either you always pad to a specific width, or you never prefix.

  • Dennis (unregistered) in reply to Dennis

    Sorry, I was a bit unspecific: Storing as floating point numbers (no matter the precision) is wrong. Proper integers are fine.

  • Officer Johnny Holzkopf (unregistered)

    Consideration: If we can't do arithmetics with them, they are not numbers, no matter how we call them. Let's say we have customer 123 and customer 456, can we do something like "customer 123 + customer 456" to get customer 579? What if we substract 100 from customer 12345? Do we have 3 times customer 23456? What is 1/12th of customer 9876? Would that make any sense? No? Then: Those are strings (or maybe even a specific native or constructed datatype), but not numbers, no matter if we "implicitely" consider them integers, floats our doubles just because they could look like those. It can even start with plain words, thought about carefully, maybe: "customer ID" (an ID doesn't imply it's a number) instead of "customer number", and on the other hand, customer IDs like "003.0278854", "CT8879556", "187/9965/0002774" wouldn't be called "numbers" either. Sadly, we routinely say things like "phone number" and then use integers... Language enables thinking. And that should have been possible decades ago.

  • Daniel Orner (github)

    The only main reason you'd use numbers instead of strings is for storage size... if customer IDs are guaranteed to always be integers (e.g. they're auto-increment IDs), they use way less storage than a string, and things like indexes are much more performant. Obviously depends on the scale of data you're working with, how big the strings/numbers are, and how important performance is.

  • ttlanhil (unregistered) in reply to Officer Johnny Holzkopf

    re: phone numbers Technically... you can int-divide and modulus telephone numbers to get area code and local part (which should be done with substrings)

  • (nodebb) in reply to ttlanhil

    For some countries. There is no standarized international phone number structure. For instance in the US a1-771-* is a number tied specifically to the D.C. area but in Chile a 56-2-* is a landline number while a 56-9-* is a mobile number and there is no regional coding. In other places like the UK the area codes vary in length, for instance London is 020 and Oxford is 01865, so good look using a modulus there unless you also coded the length rules. And some places are even weirder because the number of digits in a phone number varies, i.e. mobile numbers being either longer or shorter than landline numbers, although this rarer and generally only found in developing countries that have a mix of outdated and modern telecom infrastructure.

  • Dwaz (unregistered) in reply to Officer Johnny Holzkopf

    So you're saying that an int allows for certain operations that don't make sense on a customer number, so customer number shouldn't be an int. By that logic it shouldn't be a string either, as it doesn't make sense to take a substring, or do a string replace, etc, on a customer number either.

    The real answer is to get rid of primitive obsession in your applications, and then you'd have a customer number of type CustomerNumber, which only provides the operations that make sense, and ensures that you can never have an instance with an invalid value.

    And once you have that, it doesn't matter what type it is internally, as you'd only use that type at the boundaries of your application, when you need to interop with simple, commonly used, types. Like say when storing or retrieving data from a database.

    So having customer number be an int in your DB is absolutely fine, and arguably much better than a string.

  • Loko8765 (unregistered) in reply to AGlezB

    I wouldn't say "developing countries", since it's developed countries that will have quirks due to mixing old with new. Sweden is arguably one of the most modern telecom infrastructures (think telco Ericsson), but it is also one of the oldest, and has variable-length telephone numbers. It seems that they started with shortish ones, like five-digit 2x xxx, but soon realized that would not be enough, and so if you start with a 3 it's 3xx xxx, and if you start with 5 it's 5xx xx xx. It also varies by region (my examples are from Stockholm), and the regional prefixes also vary in length.

    https://en.wikipedia.org/wiki/Telephone_numbers_in_Sweden

  • OldCoder (unregistered) in reply to Officer Johnny Holzkopf

    And then you get dates, which actually are three numbers and usually encoded as... a string!

    Rules are there to be broken.

  • Conradus (unregistered) in reply to Daniel Orner

    That used to mean something, but the days of cheese-paring storage are gone. You can store 18-digit customer IDs with 64-bit integers in 8 bytes each. Or you can use strings, and have them take up 18 bytes each. If you have a billion customers, integers will save you 10 Gigs. Which costs more, 10 Gigs or the trouble you're borrowing by using integers?

  • (nodebb)

    I just had a flashback to the "Pentium Chip Can't Do Math" bug in 1994, but I should have been reminded of the Excel bug that sortakinda still exists.

  • Randal L. Schwartz (github) in reply to Officer Johnny Holzkopf

    And there'll be a time when your company aquires another company, and management decides that your old customers are now all "ABC1234545660" and the acquired company gets "JKL02101021".

  • Dwaz (unregistered) in reply to Conradus

    What problems? Strings will almost certainly give you more problems than a 32 or 64 bit integer will give you.

    With strings sorting will be broken, unless you think customer 11 comes before customer 2.

    Also with strings, customer numbers 5 and 005 represent different values, which they almost certainly shouldn't. Yes, you can fix that by normalizing the values, but with ints you wouldn't have to bother in the first place.

Leave a comment on “Floating Along”

Log In or post as a guest

Replying to comment #703509:

Log Out

« Return to Article