vinny42

Right... well, what can I say, except. Goodbye. I'm done here, I'll leave you guys along in your happy little bubbles... I'm off to find intelligent life...

Did you have any indexes when you tried the JOIN solutions? Because that would make your previous popst irrelevant.

Hmm, it seems that the join solution does indeed not work too well here. Looking at the explain paths it's logical because the join has to basically create a cartesian productand flatten that out to get the counts. Of course I'm going to annoy you by saying that PostgreSQL's windowing functions did the trick on 300.000 results in 0.4 seconds on an old 2GB dualcore laptop. :-)

What was the test setup?

True, if you have a few hundredthousand rows to examine you'd probably want to do it differently, using a left join and a count and a group-by; SELECT scores.id, COUNT(betterscores.score)+1 FROM scores LEFT JOIN scores AS betterscores ON betterscores.score < scores.score GROUP BY scores.id ORDER BY 2 ASC

I haven't forgotten anything, I've thought about what the actual problem is and the solution does not require an array, a loop, not even an ORDER BY clause. All the OP wants is to know how many records come before a particular record. That's one single query that everybody here should be able to work out. Actually, this problem is almost identical to this one: http://forums.phpfreaks.com/topic/283517-php-associative-array/?do=findComment&comment=1456585

Or you could just select the number of better scores per score: SELECT scores.*, (SELECT COUNT(*)+1 FROM scores AS betterscores WHERE betterscores.score < scores.score) AS rank FROM scores ORDER BY rank; or if your database supports windowing, just ask it for the ranking: SELECT id, score, RANK() OVER (order by score ASC) FROM scores

Does this data come from a database perhaps? Because databased have functions to give you the ranking, no need for messing about with PHP.

You may want to read the original question; he's not looking far a value "anywhere in the array", he's forgotten that queries have a WHERE clause. :-)

Removing messages before going live is a bad idea, experience shows that you never remove all the messages and once you have removed them, you have no way of debugging them because you have no messages. Write a prioper logger *now* and save yourself a lot of problems. It should not be much work anyway because if you have designed your code properly you should have a single function or class that executes queries and that's the only place where the logging needs to be implemented. Even if you have spammed your code with mysqli_* statements you can just rename them to a custom function that does the logging and otherwise behaves like the mysqli_* functions.

You log everything. e-ve-ry-thing. We're talking errors here, unexpected behaviour, so the more information you have, the more likely it is that you can solve the problem. And that's why we don't do that :-) The only thing users need to know is "do I call IT for this, or did I do something wrong myself?" A nice clear and short errormessage is often helpfull, if you are nice to your users they will look at the message and remember it, but anything beyond five words is simply forgotten if it's not clearly a user-error. I don't send logs as HTML emails and I don't think mailclients even do scripting in the first place (?), and I view the logs through SSH. If you do want to view it in HTML then I +1 on DavidAM; escape before you print, but log the original.

If you are viewing the error in a browser, yes. But we all agree that this does not happen in a professional environment :-)

Don't be a smartass when you're making a classic beginners mistake.

+234 The database can search for records *much* faster than PHP can. The ID is part of the record and should never be separated from it. If you remove it and you decide to sort the array, chances are that the key's will point to different rows and you're done.