strange shopping cart number

[Paul Furman]

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_l ast_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 = 117269373511726 93735 = 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));

[Kimmo Laine]

Re: strange shopping cart number

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

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 = 117269373511726 93735 = 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 autoincrementin g column if that's possible for you.

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

[Paul Furman]

Re: strange shopping cart number

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_l ast_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 = 117269373511726 93735 = 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 autoincrementin g column if that's possible for
you.
>