Actually, what I really meant was that too many crappy db designers either over- or under-normalize their tables, and as a result have way too many database queries or, conversely, an overload or poorly performing complex queries.

At OSNews, particularly as we transitioned to version 3 and “the OSNews janitor” and “soup nazi” errors become more prevalent, we had to learn a lot about how to do lots of database querying with minimal impact. Turns out that lots of the old queries could be majorly compressed. And in some cases, some sections of the site were better off using speedy little queries because some queries that used terms like HAVING were very heavy. Certain statistics pages, especially, were just brutal on the CPU, but designing the interaction differently meant getting the same data in some cases up to 100x faster.

At work we are a SQL server shop, but we use MySQL at OSNews, and it works differently enough that I’m not much aware of updating statistics or researching query paths. I can tell you that I do lots of testing on indexes, and ~ OH BOY! ~ do they make a difference!

There are two main possible reasons you are able to beat the performance of the join:

1) The query plan generated is performing a sequential scan of the table (looking at all rows) to find the matching rows, rather than internally doing individual index lookups (the disjunctive normal approach), and the table is relatively large. This means either the statistics are bad for the table or the query optimizer isn’t doing a good job.

2) You are, in fact, only interested in some subset of the rows returned, and are able to examine only the smaller number by doing individual searches. This is something which can be (and you would have) accomplished using a (partially, in your code) navigational/relational interface, rather than a fully SQL/relational interface. That would be the case, for example, if you were only concerned with whether or not at least one matching row was present, as would be the case to manually check a constraint of some sort.

Thus concludes the DBMS lesson for the day

I hear ya on all fronts. In my case, I just think the concept of extending core function via filters, hooks, and actions is really freakin’ cool. And, although there is plenty of OOP (in the form of $comment and The Loop), you’re right, learning WordPress is not hard, it just takes some time to understand the inclusion loops.

But then comes a long all their security bummers. So I guess they aren’t to be praised endlessly for their efforts.