fenway

And you're locking why?

MySQL also has DATE_FORMAT()

You sound very confused.... mysql has no idea about javascript. Get a JSON object from the DB, and then pretend the DB doesn't exist.

What's wrong with a simple (secure) script?

Echo the actual SQL statements

It's also bad practice to use reserved keywords and get away with it.

I really need to post a tutorial on joins so "wikipedia" isn't the answer to everything -- it's rarely helpful. Basically, a field can only have a single value at any one time... if you'd like to see where it has one of N values, you'll need to join N times, simple as that (or some equivalent thereof).

Agreed... it's getting silly to obtain each piece of information bit by bit.

The AGAINST can take a list of space-separated words... it's as easy as that.

Well, show us some sample data and the actual query & output.

Holy crap... 5 records from a possible 530K? These kinds of frameworks produce such mysql garbage that I want to hurl.

Far too much to describe... check the refman.

Thanks for following the posting guidelines -- good job, and welcome! Since this is a commercial product, I find it surprising that the IPB team doesn't respond to your inquiries. I agree that the "joins without indexes" is a problem -- you should turn on the slow query log, and in particular, see this regarding index usage. As for temporary tables, that can simply be the result of ORDER / GROUP by clauses that don't use covering indexes -- quite common indeed. As for fragmentation, how often are you DELETE-ing records?

You mean one that isn't an alias to "TINYINT(1)"?

Define "problem".

What makes you think the database is wrong?

First, MATCH... AGAINST -- fulltext searching -- is fundamentally different than LIKE '%whatever%'. You should consult the documentation thoroughly before making this choice. Second, if you decide to use it, you'd better add a fulltext index -- which means no InnoDB. Third, if you asking how to recode PHP, this is the wrong forum.

TLDR... I don't tend to open attachements.

Tip #1 -- post your tables structures so we can provide guidance.

That's not trivial... you'd basically need to use user variables to establish a counter for each one, and then use HAVING to filter the other ones out. It might be easier to do this in application code.

Oh, it's pure evil.... I concur. It's more of a trivia question.

Forgive my ignorance, but are you really asking for help on a public forum for your "dissertation"?

And what query produces that output?

There are all sorts of sneaky things you can do with map coordinates... but let's try something easier first. Is "hp_max" a column? Why no index on "hp"? How restrictive is the city clause? How restrictive is the hp clause? That is, of the ~10K records, how many match?

You can't store dates as INTs and use CURDATE() -- not to mention strings.