4

We are writing software to track Foo Widgets. Each Foo Widget has a serial number. The serial number is an 32-character alphanumeric string. The string is separated into five sets. Each set is separated by a dash (so the s/n is 32-characters NOT including dashes).

So for example: 11111111-1111-1111-1111-111111111111. But this may change, since our software isn't actually creating the serial numbers.

I'd like to learn about different strategies for storing the serial number and doing user validation of the serial number in the UI.

To start with, I'd like get talk about strategies for storing the the serial number in our system. This issue came up at Foo Widgets Incorporated, and there was a disagreement about whether we should store each serial numbers with or without the dashes.

I think the most flexible way of doing this (but maybe not most simple) would be to store the serial number without the dashes, store the schema of the serial number (as a regular expression), and then create an identifier that is used to track which schema is used (so later if the manufacturer changes it we can support that and perhaps both schemas at the same time).

The counter argument to this was that the dashes "are a part of the data" and that it's "not like a phone number". I'm having some trouble understanding this point of view.

|improve this question|||||
  • 1
    In your first paragraph you say: The string is separated into four sets. Each set is separated by a dash (so the s/n is 32-characters NOT including dashes). To me that sounds like the dashes are part of the serial number string. – DFord Feb 26 '13 at 20:28
  • Yes, absolutely. I've updated my question to include an example. Oh and I completely forgot they have five sets. – TheAmpersand Feb 26 '13 at 20:34
  • 2
    Odd that the grouping matches that commonly used for GUIDs. – OldFart Feb 26 '13 at 23:00
3

For the user validation part of your question, the guiding principle is Postel's law: be conservative in what you send, liberal in what you accept. That means you should always display the serial number with the dashes, but assuming you can correctly reconstruct the serial number without them, allow the users to enter serial numbers either with or without the dashes.

As for storage, it really depends on if you frequently need to do queries on subfields of the number. If you don't, it's most robust to store it in the preferred format for reading it, that is, with the dashes. That way a developer or database admin running a query from a non user-facing interface like a CLI won't have to parse it out in his head.

|improve this answer|||||
  • So I'm curious about why this method is more benefitial when reporitng on subfields. In either method aren't you still going to be getting a subfield based on the positions of the characters in the string? So the only effect it would have is the indices of the characters you wish to report on? – TheAmpersand Feb 27 '13 at 23:06
  • 1
    If you have to frequently query on subfields, then you'd want each subfield in a separate database column and combine when necessary, which is usually faster and easier than splitting when necessary. – Karl Bielefeldt Feb 27 '13 at 23:20
2

Since you are obviously thinking about the way serial numbers are formed, it's pretty clear that the format of the number IS part of the number.

There's a big benefit to keeping the dashes in place - that's future proofing. In the event that a new serial number format is desired, if all you are doing is storing the text given (after validation), then when you get a new format all you have to do is properly validate and you're done.

If you've come up with some strategy (such as the regexes you mentioned) for storing the form, then you face the possibility that the new serial number format will be something that your mechanism can't cope with, and you'll have to scramble to amend it, possibly requiring extra db updates, etc, etc.

In the end, it's just serial numbers, and while there may be many of them, don't make it more complex than it has to be - have the input validation insure the number is well-formed (and passing internal consistency checks, if appropriate), and then store it as-is.

Unless you need to do weird reporting on sub-fields of the serial numbers, AND you have millions upon millions of them, it's not worth the trouble to do anything fancy.

|improve this answer|||||
  • I don't want to make this more complex than it needs to, but I'm not sure that my proposed design is any less future-proof. If a new format comes along, we'd just add a new schema entry, and then validations could be done against both old and new schemas, right? When you say: "you face the possibility that the new serial number format will be something that your mechanism can't cope with," would you explain an example where this wouldn't work? – TheAmpersand Feb 26 '13 at 20:56
  • 1
    @AndrewPhillips - That's the problem - if there's a hole in your mechanism (and there might not be - regexes are darned powerful things), you probably won't be able to spot it now, because it'll be something so totally outlandish that it would never have occurred to you that anyone would do something like THAT in a serial number. It's obviously your design and your call, but unless you know there's a plan afoot to change the serial number format, why do more work now, which may never be needed? – Michael Kohne Feb 27 '13 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.