[wp-hackers] Taxonomy Mirrored Posts Best Practice?

[Mike Schinkel]

Hi all:

I have another "Best Practices" question to ask about mirroring taxonomy terms with posts.

Back at the beginning of July I asked if anyone had code to synchronize custom taxonomies with custom post types[1] and didn't get much response so I ended up writing it and it is working pretty well. I will release as a plugin as soon as I have time to package it. It might even make a nice set of APIs to include with WordPress core in a future release.

However I have concerns about how I implemented it and want to get other's opinions.  Basically the three options to link custom post type records with their corresponding taxonomy term records are summarized as:

1. Using Matching Slugs 
(i.e. $wp_posts->post_name==$wp_terms->slug.)

2. Using wp_postmeta Records 
(i.e. $wp_posts->ID=$wp_postmeta->post_id && $wp_terms->term_id=$wp_postmeta->meta_value && $wp_postmeta->meta_key='_mirrored_term_id')

3. Using the $wp_term_taxomony->parent Field 
(i.e. $wp_posts->ID=$wp_term_taxonomy->parent)

Let me give an example.  Assume you have a "movie" custom post type and you want to add "actor" and "genre" taxonomies but also want "actor" and "genre" custom post types so that when you add an actor post record (i.e. "Brad Pitt" or "Angelina Jolie") you get corresponding "Brad Pitt" or "Angelina Jolie" taxonomy terms that link to their associated post type record. This will let you associate the "Brad Pitt" and/or "Angelina Jolie" post type records with each of the movie post type record for the movies they starred in by using the taxonomy selector metabox in the movie edit screen; it provides lots of functionality "for free."

As first I implemented the functionality via #1 because it was easiest but Michael Pretty pointed out[2] that using matching slugs is a bit too fragile and thus not recommended.

I implemented the functionality via #2 using a wp_postmeta->meta_key of "_mirrored_term_id" and storing the associated $wp_terms->term_id in $wp_postmeta->meta_value, and $wp_posts->ID in $wp_postmeta->post_id, of course.  This works nicely except it is yet another postmeta record and more importantly it uses a non-indexed longtext field to store what ideally would be an indexed bigint field.

The other option I considered was to use the $wp_term_taxomony->parent field to store the wp_posts->ID field for a given association. I could use that field because, for my use-case I'll never use that parent field which I assume was meant to be a foreign key back into the same table (or many to wp_terms->term_id, not sure.) This parent field *is* a bigint field and while not indexed and index could easily be added if performance becomes an issue. However, I'm concerned that some other plugin might overload the use of that field two and either clobber my use-case or my plugin might clobber theirs.  Or maybe someone already knows of a use-case that would make this either impractical or downright incorrect?

So I'd love to get feedback on this.  If you are implementing the same (or if you already have) which way would/did you choose to go, and why?

-- Option #2?
-- Option #3? 
-- Or some 4th choice I didn't consider? 

Thanks in advance.

-Mike

[1] http://lists.automattic.com/pipermail/wp-hackers/2010-July/032826.html
[2] http://lists.automattic.com/pipermail/wp-hackers/2010-May/032205.html