Depending on your needs, here is another tack to think about (I know, everyone else will be gasping and running for air...) A few years ago I had to make a shopping cart. I had an archaic system that would not share information with my web/db server, so I had to write a query to dump the products, quantity, price levels, etc out of it to a CSV file. I then used perl to get the file, reformat it into SQL files, then run an empty of the table and recreate with all the data that I just got off the server. To get past the naming conventions and such and NOT lose any linked tables, I did my joins and such off the product ID. The Caveat to this was that the products (even those we no longer sold) stayed in the system for about 6 months, and by the time we were ready to purge those, the orders were saved and could not be deleted (PDF and as saved data) so that was never a problem. That solved the product counts for me (since the bosses were a bit anal about having accurate product counts and such) and kept that table tidy. Customers was not so tidy, nor wore the other tables. But you can only work with what you can do. In short, unless you have a very good reason and safety checks to keep your data from getting lost from other tables, you might need to rethink why you want that. If you want to chew the fat and talk design, shoot me a message off-list and I'll be glad to help. Wolf -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
