Michael, why do you need to link de manufacturer table with de product
table? I think that you have to clarify the design of your db and your
business rules first... for instance, if you have to reuse the IDs (the
barcode and de manufa cturer ID), then you will create new tables in order
to preserve your history (I supouse that it will be interesting to know that
in 1999 the transactions of the ID 111 corresponds to Michael!!).
Business Process Outsourcing
Tel: 54 11 4316 5754
Fax: 54 11 4316 5734
From: Michael Conway [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 21, 2002 9:15 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DB] Questions regarding primary keys, updates, and
I have been working on an e-business project and have a product table
and manufacturer table that are linked via barcode and a manufacturer ID
(both primary keys in the tables mentioned). For now, I have been
setting the manufacturer's ID manually, primarily for that rare instance
where a manufacturer and its products are dropped from the database, but
the number should be reused. Is it better or possible (without
complications) to use autoincrement and simply delete the product
information and manufacturer information while leaving the ID column
intact for a later update operation with a new manufacturer and its
products? I suppose only one table (the linking table?) should be set to
autoincrement and that ID number used to populate the remaining tables
depending upon that number for insert operations. The code is probably
simple, but my head is already swimming. I suppose what I am looking
for is "best practice" advice from seasoned db administrators.
A second question, which may be moot if autoincrement is the best way to
go, is why I keep getting an duplicate key error despite using IGNORE in
my mysql update scripts. Keep in mind that the update is completed
anyway (even without using IGNORE) but the abort prevents an
acknowledgement script which is essential in unregistering sessions
crucial in future update operations.
The information in this email is confidential and may be
It is intended solely for the addressee.
Access to this email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure,
or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful.
When addressed to our clients any opinions or advice
contained in this email are subject to the terms and
conditions expressed in the governing KPMG client engagement
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php