[wp-trac] [WordPress Trac] #14513: Time for a wp_post_relationships table?
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
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