Posted by Paul Furman on 02/28/07 21:58

Kimmo Laine wrote:

> Paul Furman kirjoitti:
>
>> I don't know, maybe this isn't strange but someone else set up the
>> shopping card coding I'm working with, the way it works is to get the
>> time() in seconds like 1172693735 and that's the shopper_ID number and
>> the shopping_cart_last_modified number is generated the same way once
>> they check out... then an invoice number is generated by subtracting
>> the two numbers (shopper_ID is older from when they registered). Is
>> this strange or bad or clever and efficient? Or maybe I'm misreading
>> the code. While unlikey, it seems possible to get the same number twice.
>
> If two customers spend the exact same time shopping then yes, highly
> unlike but possible. The bigger problem is that there is no sequence.
> Sequent invoice numbers can be 1234, 43, 345345345, 5434 which in my
> mind makes absolutely no sense, I'd call them 1, 2, 3 and 4...

Thanks for your thoughts.
It looks like I was misreading and it wasn't subtacting the two
timestamps but concatenating them with a hypen!
1172693735-1172693736
customer_ID."-".shopping_cart_ID
(both are timestamps)

So that was a safe tactic to create unique numbers but the numbers are
too long for a human to read. I've decided to go with 7 digits of
seconds since 1-1-2007:

//seconds since 1-1-07 (-37 years))
print " ".(time()- (31556926*37));

looks like:
Invoice Number: 5091491

The real purpose here is looking up the invoice number on the credit
card site to make adjustments and credits & such, and we'll also be able
to check the name, etc. it's just a quick way to find an order. And I
don't want to have to re-write more than necessary. This project is
killing me, I'm not that skillful :-)

Old invoices end up being negative and 10 digits:
-1167606262
but those are already paid & delivered so it doesn't really matter.

> If only the first or second timestamp would be used as the id, then at
> least they'd be unique and in sequence. I guess the original designer
> was maybe worried about saving some drive space and optimizing it like
> that, but it actually creates the two problems of possible collision and
> non-sequantial order. Using a few bytes more for storing the whole
> timestamp is totally worth it when you get unique and sequential id's.
>
>> And the numbers end up being almost completely random, with no
>> sequence for sorting or clue of the actual date. In fact the invoice
>> number is only generated on the fly when composing a confirmation
>> email and on the admin interface to the shopping carts.
>>
>> Maybe it would make sense to concatenate the numbers... at least that
>> would be sequential but would be a huge number... I'm setting up
>> credit card payment and we'll need to use the invoice number to find
>> transactions for issuing credits and such.
>>
>> 1172693735 + 1172693735 = 11726937351172693735 = too long!
>
> It depends, for a human it is too long, for a computer it's just a drop
> in the ocean. I mean if a human needs to type that number somewhere then
> it definately is too long, but just for computer to computer it's no
> different from 123 and 456.
>
>> Surely we'd never have more than 9999 invoices a year so the invoice
>> number could just be 070001, 070002, etc.
>
> That's not a bad idea at all.
>
>> Or start counting time on 1-1-07 so the number is 37 years worth of
>> seconds smaller like: 5,088,686 I'm not too concerned about two people
>> checking out at the same second. That way I don't need to add a new
>> field to the database or change much. That would grow by 10,800
>> seconds a year and 432,000 in 40 years: as long as I'll be alive :-)
>>
>> Is that a sensible way to approach this?
>
> I'd just use the databases built-in automaticly incrementing field type,
> in fact in our own invoicing system both user id's and invoice numbers
> come from an autoincremented databasefields. I've never ever encountered
> any problems with that. Just let the database worry about uniquity
>
>> //seconds since the Unix Epoch (January 1 1970)
>> print time();
>>
>> //seconds since 1-1-07 (-37 years))
>> print " ".(time()- (31556926*37));
>
>
> or something like date('ymdHis'); maybe? But really, I'd just trust
> whatever the db uses for autoincrementing column if that's possible for
> you.
>

[Back to original message]