[wp-hackers] A "terms" table

[Peter Westwood]

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 
access.

>> 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 
dropped it!

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 ????)

westi
-- 
Peter Westwood
http://blog.ftwr.co.uk