On Mon, Mar 30, 2009 at 9:13 AM, Sebastian Muszytowski <s.muszytowski@xxxxxxxxxxxxxx> wrote: > haliphax schrieb: >>> >>> [..cut...] >> >> Except when your primary key value rolls over, or fills a gap between >> two other rows that was left when a row was deleted/moved/etc... there >> has got to be a better way than grabbing rows in descending order >> based on the auto_increment value. >> >> Are you doing the inserts one at a time? If so, why not just use code >> to remember what you put in the DB? >> > > I do the inserts one at a time, i could use code to remember but i think it > would be very slow when i have too much users. > > The second thing that aware me from doing this is, why use/build ressources > when you could use others? i think why should i use and add another system? > I work with mysql already and when php+mysql have the function i need it's > better and i don't waste ressources :) Insert 100 records. Delete 50 of them at random. Now do your "grab the last few records and sort them in descending order" trick and see where it gets you. Not trying to be rude, it just doesn't seem like you read any of what I wrote in my last message. Also--if you're already doing the inserts one at a time, you're not going to lose any noticeable speed by tracking the last 5 inserted rows or so. You are not working with an embedded system--this is a high-level programming language. Why is everybody always so concerned about adding two or three lines of code like it's going to slow their system to a crawl? Unless you're messing with file IO, chewing up gigantic amounts of RAM, or performing cryptography/compression, you don't need to be quite so frugal with your methods. I'm not saying you should be sloppy--just that you shouldn't completely disregard an option because it adds 1 term (NOT magnitude) to your project's Big-O Notation measure. My 2c. Go with ORDER BY asdf_id DESC if it suits your fancy. -- // Todd -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
