[wp-trac] [WordPress Trac] #14513: Time for a wp_post_relationships table?

WordPress Trac wp-trac at lists.automattic.com
Thu May 12 15:48:27 UTC 2011

#14513: Time for a wp_post_relationships table?
 Reporter:  mikeschinkel     |       Owner:
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Post Types       |     Version:  3.0.1
 Severity:  normal           |  Resolution:  maybelater
 Keywords:                   |
Changes (by dougal):

 * cc: dougal@… (added)


 "Wordpress, to all intents and purposes, no longer uses SQL as a Relation
 Database Management System, but rather, uses SQL as a data store for a
 custom relational model which just so happens to use SQL as the storage
 layer. Sure, Wordpress makes use of indexes and other features to speed up
 access, but these could be used if Wordpress stored its data in a B-Tree,
 or any other structure."

 I think this is a pretty good point. We barely use the database as an
 RDBMS. Oh sure, we *do*, but the key here is that we care more about the
 relations at a 'context' level than at a 'data integrity' level. WordPress
 is **all about** context of data, if you think about it.

 And it's not like there isn't precedent for introducing new tables or more
 complex features before. Look at our taxonomy system -- we could have
 added support for custom taxonomies in *much* simpler ways. It was
 originally going to just be a simple 'tags' system. But instead, we used a
 system which, while complex, is very flexible. And to the best of my
 recollection, the whole WordPress world was not screaming "we want custom
 taxonomies" at the time it was added. __Most__ people were getting on fine
 using categories and postmeta (which is one of my proudest contributions
 to WP core, despite my in-hindsight mistake of the multiple-value
 implementation). But look at all the cool things that people have done
 with custom taxonomies since then!

 This is pretty much the same. To me, many-to-many post relations (or
 object relations in a more general sense) are just going to be a natural
 evolution in WordPress. I really don't understand the reluctance here.
 Others have already pointed out use-cases where post-to-post relations
 make things much easier than trying to wrap things into taxonomy and/or
 post-meta. Those solutions only work for a sub-set of the proposed

 But if you wanted to try to build the next IMDB or AllMusic, you pretty
 much **need** many-to-many post relations. The music scenario can be even
 more complex than the movie database scenario. At least with movies, the
 list of actors in a film stays constant over time. With music, the list of
 musicians in a band can change not just from album-to-album, but from
 song-to-song (guest musicians, for example). Musicians can be members of
 more than one band at a time. Or be a musician for one project, and a
 producer for another. Or both at the same time on the same project. You
 probably *could* implement all that with taxomomy and postmeta, but you'd
 end up with a bunch of custom code that was only applicable to that one
 particular project. For the next project, you'd do a bunch of *similar*
 implementation, but just different enough that you'd end up rewriting a
 bunch of code. Plus, I bet you'd end up with certain relationship queries
 that would be very inefficient, because you'd have no good indexes for
 them. A good many-to-many relationship API in core would make this type of
 thing much easier, and much more portable between projects.

 So, we don't know what the implementation should look like yet. It might
 be version 3.4 or later before it goes in, but I think that something like
 this is inevitable. We need to start thinking about implementation. One
 day we'll be looking back at some awesome theme, or plugin, or custom site
 built on this, and saying, "Remember when...?"

Ticket URL: <http://core.trac.wordpress.org/ticket/14513#comment:84>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list