Re: php mysql problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux