Unclear elements
It would be useful to clarify the following points:
- Is the
-
currently stored in the string ? - Is the length control on the client side based on the visible string or on the length of the data sent to the backend ?
- Is the unique identifier a concatenation of two values (i.e. could there be
AB-123456
andCD-123456
? Or is123456
the real identifier andAB
is just an additional info ?) - Is the additional suffix
-1
limited to a single digit ? - Is the additional suffix an arbitrary extension of the id length (i.e. the separator is just here to facilitate reading) ? Or is there a meaning behind this suffix (e.g. would there a a conceptual relation between
AB-123456-1
andAB-123456-2
) ?
Suggestions
If answer to (1) is true, then the easiest approach would be to get rid of the separator:
AB-123456
AB1234561 instead of AB-123456-1
If answer to (2) is visible, then you have a reason more to get rid of the separator. But really, the front-end team should be more flexible : in the 80's it was a big deal to make a field longer, but in the XXIst century, really ?
If answer to (2) is backend, then you have a reason to get rid of the separator in the DB, but adatpt the display to insert the -
where the user expect them.
In other cases, of course, going hexadecimal is a way to compress the central number. But you gain only one char, since you'll still need 5 hex digits to represent 999999
. If you go for a base 32 instead of a base 16, you could spare 2 chars, encoding your number on 4 digits.
Note that you cannot find an encoding scheme that is smaller than 4 printable characters. With a base 95 (using as digit all the printable chars of the ascii character set), you'd still need 4 chars. If non printable chars would be tolerated, you could compress the number on 3 chars (since 20 bits are needed to encode a 6 decimal digit number).