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

[WordPress Trac]

#14513: Time for a wp_post_relationships table?
-----------------------------+----------------------------------------------
 Reporter:  mikeschinkel     |        Owner:                
     Type:  feature request  |       Status:  reopened      
 Priority:  normal           |    Milestone:  Future Release
Component:  Post Types       |      Version:  3.0.1         
 Severity:  normal           |   Resolution:                
 Keywords:                   |  
-----------------------------+----------------------------------------------

Comment(by Denis-de-Bernardy):

 Replying to [comment:18 mikeschinkel]:
 > Denis, another idea besides a specific table could be to simply add a
 `parent_id` to `wp_term_taxonomy` and overload it to allow for post
 relationships?  I don't know if doing so will have unintended consequences
 with normal usage of the taxonomy system as the `nav_menu_item` post type
 did for plugin queries and such, but it might be manageable?

 Well, if you "must" know, the reasoning behind the suggested table set
 above breaks down to my own research, years back, in semantic indexing
 algorithms. In essence, the most generic set of tables you can have amount
 to a nodes (id, parent, type) table and a meta table on the same. It
 breaks down to the fact that at some point you need to store data in a
 relationship (say, how much merchandise was moved from a premise to the
 next), and it follows that a relationship is a node in it's own right (or
 vice versa).

 However, the same research (never published, sorry) also showed that it
 didn't scale well, and that two tables (plus the obvious meta) As
 described further up scaled a lot better for data designed to be displayed
 on a screen (in that particular case, the base case was a bookstore db for
 web use), because in web use cases it's rare to store data in a
 relationship (besides the relationship itself).

 Fwiw, I've been periodically reinvestigating the topic as a hobby since
 then, until I came to a final (and dismissive, I'll confess) conclusion
 that it's a lot better to have multitudes of tables, with a generic API
 that knows which table to hit. At this point, however, you need to take
 into account the assumptions behind WP, ie that a db is a huge array that
 stores generic information to be processed by php, rather than some
 relational database management system that, low and behold, might contain
 an sql trigger.

 It thus seems, to me, that things point towards using two tables, nodes
 and relationships (whatever they're called then, plus two meta tables),
 for storage at some point. Maybe in a year, maybe in five, but I trust
 we'll eventually get there. And when we get there, posts and terms will be
 merged at the same time or shortly after because it'll make little sense
 to some that we've duplicate code all over the place.

 Based on the replies I don't sense the slightest interest for 3.1 though.
 Or 3.2, for that matter. Maybe this should get revisited when php6 returns
 a fatal error when checking for magic quotes? It might be a good time to
 break absolutely everything...

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