On Mon, Mar 30, 2009 at 9:13 AM, Sebastian Muszytowski
<s.muszytow...@googlemail.com> 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

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

Reply via email to