[wp-hackers] A "terms" table

[Matt Mullenweg]

Robert Deaton wrote:
> I would swear you were highly overweight if I didn't know any better.

I'm working on it.

> One of the first rules of SQL has always been to not fetch more than
> you need, to allow sorting and searching to be done on the SQL side,
> etc. This breaks that fundamental rule.

In the context of displaying a post the categories and tags for that 
post aren't more than we need, they are exactly what we need. It's an 
index lookup.

> The bitfield also introduces new things. Let's face it, the APIs for
> fetching things from the database are horribly incomplete and will
> never ever possibly cover all the things that plugins will want to do.

If our APIs are incomplete, that's a separate and unrelated bug to the 
underlying data structure. A plugin should never talk to the core DB 
tables and fields directly.

> So, how about a plugin that wants to fetch all the tags to do some
> magic? Well, with a bitfield, that plugin now has to fetch all the
> categories and all the tags, and then sort through with bitwise
> operations and discard the categories which they don't care about.

You can get one or the other on the query level, no reason to select 
both. It's also something we could pretty easily create a wrapper 
function for, if there isn't one already.

> I think you missed a noun in the last clause of the sentence. Who
> thinks it is? 

Oh sorry, I think there are too many. I agree that it's better to have 
more fast and light queries than fewer heavy ones, but I don't think WP 
is yet fully optimized in this regard, though 2.1 was a step in the 
right direction.

> Are you gradually moving us toward dropping this table altogether and
> moving it all into postmeta?

I thought about this a lot, but that would make it pretty difficult to 
do a query against posts in category or tag X, which I think is a pretty 
common use case and one we should weight the schema toward.

> But like you said earlier, ketchup and mayonnaise are two different
> things. Why would we be trying to put them together?

I'm not going to try and stretch the metaphor too far, but I think at 
the base level they do something that can be described and stored in 
exactly the same way. I guess you could think of it as the ingredients 
that go into each. Perhaps a better analogy would be ketchup and 
spaghetti sauce.

> I disagree. Especially because the implementation is lacking so many
> features that other tagging plugins have done well for some time now,
> new plugins are bound to be forced to write their own queries to
> interface with this table. And when they don't work anymore in the
> next version, someone's gonna be pissed.

I think if we cover the basic CRUD operations, every missing feature I 
can imagine is doable. If people want to talk to the DB directly, they 
should be smart enough to know that means they'll have to update their 
plugin accordingly. Fortunately, with a regular release schedule and an 
Open Source codebase like ours there aren't really surprises like that 
you won't know pretty far in advance.

> I agree, there is something better about shipping and iterating, as
> long as the initial shipment has something that is not fundamentally
> broken.

I don't think anything we've talked about on either is fundamentally 
broken, especially from a user point of view.

Historically we've found that the things that are actual issues are very 
different from the things we've anticipated to be issues. I don't think 
this is unique to us, but is a general tenet of software design and 
development in general.

-- 
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com