[wp-hackers] A "terms" table
m at mullenweg.com
Sun Apr 15 23:27:42 GMT 2007
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
> 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
> 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
> 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
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.
http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
More information about the wp-hackers