strange shopping cart number

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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.

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!

Surely we'd never have more than 9999 invoices a year so the invoice  
number could just be 070001, 070002, etc.

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?

//seconds since the Unix Epoch (January 1 1970)
print time();

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

Re: strange shopping cart number

Paul Furman kirjoitti:
Quoted text here. Click to load it

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...

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

That's not a bad idea at all.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirviö | Gedoon-S @ IRCnet | rot13(xvzzb@bhgbyrzcv.arg)

Re: strange shopping cart number

Kimmo Laine wrote:

Quoted text here. Click to load it

Thanks for your thoughts.
It looks like I was misreading and it wasn't subtacting the two  
timestamps but concatenating them with a hypen!
(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:
but those are already paid & delivered so it doesn't really matter.

Quoted text here. Click to load it

Site Timeline