[wp-hackers] Custom list of posts per user
mikeschinkel at newclarity.net
Wed Sep 15 18:29:25 UTC 2010
On Sep 15, 2010, at 7:00 AM, Otto wrote:
> On Wed, Sep 15, 2010 at 5:39 AM, Mike Schinkel
> <mikeschinkel at newclarity.net> wrote:
>>> Remember that you can have multiple meta values with the same key, so you
>>> don't need serialization at all.
>>> You just have to decide which table makes more sense: postmeta or usermeta.
>> If it's purpose is to store a bigint foreign key in a longtext field, especially if you might need to index on it, I'd say neither makes more sense. JMTCW.
> That really depends on your use cases. How is he using this data? Are
> you always retrieving all the data for each user? Do you need to join
> on it? If you don't need to do every possible thing with it, then you
> don't have to go all normal form on it, and you can get optimizations
> that you wouldn't have otherwise.
> Using the user_meta would be quicker if a) the number of items in the
> list was small and b) you didn't need to access them in the reverse
> direction (that is, you only ever pulled the list for a single user,
> not a list of users who had the item in their lists).
Yes, you are correct. Clearly I spoke out of turn. For small data sets or large ones that don't require an index on the foreign keys the meta system works brilliantly. It's when you exceed those constraints that WordPress doesn't offer a built-in table to address those use-cases in a performant and robust way for which adding a table would be the solution.
Although I know certain core team members don't agree with the need for a post-to-object relationship table I think we're seeing demand because of CPTs and it would be nice if we could share a table design and API so that each of us don't have to create our own incompatible ones. And the only current mechanism for that to happen is for it to get added to core. FWIW.
P.S. Or maybe this could be a core plugin to test the waters?
More information about the wp-hackers