On Thu, 31 Jan 2002, DL Neil wrote: ... > > What should be understood is that MySQL's implementation of AUTO_INCREMENT requires >a particular/different > philosophical view: that first the 'primary row' is to be stored, then the >AUTO_INCREMENT data captured, and > finally the dependent row is stored (in the second table) - a reversal of the >earlier-mentioned approach. As > soon as one understands how the whole job is to be done, the logic of the individual >components becomes > 'obvious'. (and the old dog has to remember his new tricks!) ... I've run into one case where knowing the "next" ID would be useful was where file names, being stored in the record contained the ID (for performance reasons or maybe my bad design) since I was storing graphics separately (for web work it makes great sense since the name needs to go on the page not the data). I had to do an insert, get the LAST-INSERTED-ID, and then update the record. I suspect that this is really faster if there are multiple updated going on than locking the table. Also, it enables me to use fixed length records.
Didn't even think of locking the tables. BTW: an earlier poster mentioned DB2. You have to have a separate Key table and use an Update with a Sub Select and lock that table to get the next key since DB2 still (as of the version I was using) have auto-increment fields. Don't know if its true, but a DBA I worked with insisted that MicroSoft's SQL's auto-increment was flawed so we had to do the same thing there, even though it did have auto-increment. Perhaps a hold over from the "doing it by hand" days.. Sincerely, William Mussatto, Senior Systems Engineer CyberStrategies, Inc ph. 909-920-9154 ext. 27 --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
