[wp-hackers] A "terms" table

[Ryan Boren]

On 4/15/07, Matt Mullenweg <m at mullenweg.com> wrote:
> Regardless of the UI and philosophy behind categories, tags, and ooga
> booga, on a data level they're still mapping a set of terms to an item
> in post_content.
>
> In WP a term has three important things: an ID, a human-entered name,
> and a URL-friendly slug. We use the ID in our relations instead of the
> slug because it's more efficient and slugs are not necessarily unique
> (because of hierarchy).
>
> Having "dogs" in a category table have one ID and "dogs" in a tag table
> have a different ID is a long-term deck of cards that we will seriously
> regret later. It's MUCH harder to reconcile items with internally
> different IDs than it is to split out unique IDs into different tables.

I agree with these points.  These points are the reason I tried to
make the current design work.

> As for some of the bit and count fields currently causing grief, I would
> argue the solution for that isn't a separate tags table, but a separate
> table specifically for that type of data. In Drupal for this
> infrastructure they have a term_data, term_hiercharchy, term_node,
> term_relation, term_synonym, vocabulary, and vocabulary_node_types
> tables. I think that might be a little more than we need, but there are
> some concepts there we could pretty cleanly combine into a single extra
> table that isn't called categories or tags, and will provide a good and
> scalable foundation for years to come.

The presence of category_parent and the count fields are the crux of
my problem with the unified table.  They cause a lot of grief and kill
any future-proofing you think you're getting by having a unified terms
table.  If you're open to a new table for this information, I think I
could get behind that.  I'll give it some thought.

Ryan