[wp-hackers] A "terms" table
peter.westwood at ftwr.co.uk
Sun Apr 15 20:46:14 GMT 2007
Ryan Boren wrote:
> 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.
I also agree with this.
I do feel we need a super light terms table that just stores the three
important things - ID, name and slug this would be wp_terms.
We then would have one table per term usage type with the linkages in
them. i.e post2cat post2tag link2cat etc. - post2cat and post2tag could
live as postmeta data although this would make them more expensive to
>> 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.
It would be nice to be able to restore the lost functionality for links
in this process too - i.e. the ability to customise the lists in the
admin ui that was lost in 2.0 - a lot of people used this and we just
This probably means we need tables like: link_cat_extras and
post_cat_extras (these need better names and maybe they can be merged or
can be extra columns in the wp_terms table ????)
More information about the wp-hackers