Yo Dan,
your back! guess the honeymoon is well and truly over then ;-)
Daniel Brown schreef:
On Sat, Sep 13, 2008 at 8:14 PM, tedd <tedd.sperling@xxxxxxxxx> wrote:
While you might think an order number should be something else, keep in mind
that an order is simply an order. It is a point in time where a customer has
agreed to purchase something and you have accepted and have cleared that
purchase for that payment through some sort of purchasing scheme.
One of the best schemes for developing a unique order number that
is not only unique to the system, but is also readily human-readable
would be to use an auto_increment value appended to a date string.
For example:
<?php
$today = date("Ymd");
$increment = $numberFromDB; // This routine would depend on your
database (MySQL, PostgreSQL, etc.)
$orderNumber = $today."-".$increment;
?>
From the above, you'd get an order number similar to 20080913-1048.
This means that it's not only unique, regardless of how many
orders come through in the same second, but ordering by time and date
is easier, and on paper, you can easily tell when an order was placed.
a handy trick, I would suggest this belong in the display layer of the
app not in the DB. I was originally taught DB stuff from someone who was hot
in FoxPro in the 80's ... back then it was normal to encode all sorts of info
into unique identifiers (much like the way you describe) for the simple reasons
of lack of disk space, cpu power and screen space ... these days
best practice is generally accepted to be that a unique identifier is purely
that and no more ... adding 'cruft' to a UID pollutes it and I would hazard to
call it data-bastardization[tm] ... the date can (and should) be stored as
a seperate field, output from the DB can always be displayed as you described.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
