On Wed, 2015-06-17 at 12:31 -0500, Booth Martin wrote:
Its not clear to me what volumes he is anticipating. If he is at
899,999 now in a file that is 10 years old then he doesn't need base36.
That is way overkill. On the other hand, if volumes are such that he
is needing base36 then my guess is that he might as well bite the bullet
and expand the field, cuz base36 is just a band aid for him.

My personal preference would also be to bite the bullet and increase the
size (assuming the "number" isn't used in some form of combined set that
is limited in some way, eg. an ISBN is made up groups that have varying
lengths depending on imprint which reduces the number of titles allowed
for imprint, but the overall length is constant), but for a slightly
different reason...
By the time every program has been checked to make sure that none of
them do something silly like put the character "number" into a real
number field it would have been just as easy to have reviewed them as to
the effect of changing the length... but then again, if this "number" is
used within/part of other keys to other files the cascade of other files
that need changing could be huge... but again the issue over the
"number" used as a real number could also affect the other related
files.


Properly evaluating anticipated volume is a part of the decision
process, much more so than sticking in a base36 solution that will be
nothing but a confusing maintenance and design headache going forward.

On 6/17/2015 12:13 PM, John Yeung wrote:
On Wed, Jun 17, 2015 at 12:40 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:
My first thought is to do it the other way round. Put the letter to the
front, not to the rear. A99999,B00000, B00001... etc.

You're missing a couple of key points though. First, it's not like
he's really looking to make the first character a "digit" and the
subsequent characters "letters". He wants to make *every single
character* able to take any of 36 possible values. For example, at
some point, the field in question will have the value '9AA3XY'. He
wants the next one to be '9AA3XZ', and then the one after that to be
'9AA3X0'.

The second crucial point is: He wants to keep the natural EBCDIC sort
order. (Or collating sequence, to use IBM's terminology.) In EBCDIC,
the letters come before the digits. So the value 'Z99999' actually
comes *before* '000000', or indeed, anything starting with zero. The
next value after 'Z99999' would be '0AAAAA'.

John Y.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.