On Sun, 2008-09-14 at 03:42 +0200, Jochem Maas wrote:
> 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.
>
>
>
I think I see what your problem is. Basically, you've set the tables up
in the wrong way. Every order system I've used has one table for the
orders, one for the customers, and one for the items attached to an
order. This makes management a lot easier, and you get to use those
auto_increment values you so need. From what you've been saying I'm
guessing this is a custom built system, so hopefully it shouldn't be too
hard to change now if it's not finished. If it's something you have
purchased to use... well, I'd look for something else...
Ash
www.ashleysheridan.co.uk
