At 5:38 PM -0500 9/13/08, Tom Shaw wrote:
Can anybody give me any good reasons not to use a time stamp as an order
number in my shopping cart. It seems to me that the number is guaranteed to
be random and it saves having to make an extra time column to keep track of
the order. The only small concern I have is the chance that somebody orders
at the exact same time as somebody else but the chance of that has got to be
incredibly small but possible.
<opinion based upon experience>
While time stamp is usually unique, it isn't always -- don't assume
it will be unique.
An order number should be a unique auto increment id (i.e.,
sequential) in your table. It should be representative of the
customer's order -- it should contain the customer id;
shipping/billing address; what the customer ordered (all items
ordered); the time-date of the transaction; authorization code
provided by the clearing house; and payment amount -- and basically
nothing else (i.e., No credit card information).
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.
It makes no difference if your dB is normalized, or relational, or
some stock-boy working in a warehouse, or a phone order operator
pressing an "Done" button. It is simply an order number.
While you might think a microtime stamp would work, a unique auto
increment id will work better.
</opinion based upon experience>
My second question is I've designed a very simple Postgres database wrapper.
The methods are exactly what you would assume to see in any db wrapper a
pg_query, pg_fetch_array. My question is in the db wrapper, is there an easy
way to always include the table name as an index in all my pg_fetch_array
returned results? The reason I ask is when designing my tables I'm delegated
to prefixing my column names i.e. users_name instead of just name or
forum_posts instead of just posts to make sure there's no collision.
I'm not sure if I understand your question, but I'll try to answer
what I think you are asking.
Regardless of the dB, I find it best to have a configuration file
that contains and defines all the variables re the dB (i.e., db_name,
db_user, db_password, db_table<whatever>, and so on).
That way, all you have to do is to include that file in your scripts.
If you want to change something, you can change it in just one file.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
