Re: 2 Questions.

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@gmail.com> 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.