Skip to main content
added 354 characters in body
Source Link
Christophe
  • 80.6k
  • 11
  • 132
  • 199

Unclear elements

It would be useful to clarify the following points:

  1. Is the - currently stored in the string ?
  2. Is the length control on the client side based on the visible string or on the length of the data sent to the backend ?
  3. Is the unique identifier a concatenation of two values (i.e. could there be AB-123456 and CD-123456 ? Or is 123456 the real identifier and AB is just an additional info ?)
  4. Is the additional suffix -1 limited to a single digit ?
  5. 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 and AB-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).

Unclear elements

It would be useful to clarify the following points:

  1. Is the - currently stored in the string ?
  2. Is the length control on the client side based on the visible string or on the length of the data sent to the backend ?
  3. Is the unique identifier a concatenation of two values (i.e. could there be AB-123456 and CD-123456 ? Or is 123456 the real identifier and AB is just an additional info ?)
  4. Is the additional suffix -1 limited to a single digit ?
  5. 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 and AB-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.

Unclear elements

It would be useful to clarify the following points:

  1. Is the - currently stored in the string ?
  2. Is the length control on the client side based on the visible string or on the length of the data sent to the backend ?
  3. Is the unique identifier a concatenation of two values (i.e. could there be AB-123456 and CD-123456 ? Or is 123456 the real identifier and AB is just an additional info ?)
  4. Is the additional suffix -1 limited to a single digit ?
  5. 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 and AB-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).

Source Link
Christophe
  • 80.6k
  • 11
  • 132
  • 199

Unclear elements

It would be useful to clarify the following points:

  1. Is the - currently stored in the string ?
  2. Is the length control on the client side based on the visible string or on the length of the data sent to the backend ?
  3. Is the unique identifier a concatenation of two values (i.e. could there be AB-123456 and CD-123456 ? Or is 123456 the real identifier and AB is just an additional info ?)
  4. Is the additional suffix -1 limited to a single digit ?
  5. 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 and AB-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.