Re: The case of outnumbered numerator

On Wed, Jun 17, 2015 at 1:31 PM, Booth Martin <booth@xxxxxxxxxxxx> 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.

No, if it took 10 years to get to '899999' then he's on pace to run
out in a little over a year.

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.

Well, I think we can all agree that base 36 would be a Band-Aid regardless.

But base 36 is a pretty powerful Band-Aid. With 6 digits at base 10,
he started with a space of one million possible values. He's almost
burned through 900000 of them, meaning he really only has 5 digits
left to play with. But even with just those 5 digits, in base 36
that's a space of over 60 million values.

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.

Let's not jump to the conclusion that OP has failed to take everything
into consideration. Maybe he has and maybe he hasn't. Sometimes you
have to get something done by a certain time, and that amount of time
isn't always enough to achieve the solution you would prefer.

In this particular case, I'm actually not even 100% sure that
expansion is the *cleaner* option. I mean, we would need to know how
that field interfaces with other stuff. If it were a numeric field to
begin with, then yes, absolutely, expansion would be the obvious way
to go. Of course, it would be pretty much the *only* way to go.

But with a character field, expanding it brings up questions like:
Should the preexisting values be padded on the left or right? Should
they be padded with blanks or zeros? It's not necessarily as
straightforward as you make it sound.

John Y.