[wp-hackers] Like Posts - Store Data in DB, User_Meta or Post_Meta

[Gregory Lancaster]

So I want to place this into a custom table instead, and if I am to do
that, to minimize the sql load I wont be using arrays.  Rather the better
option would be to create a new row for each like, with one col for the
user_id that liked the post, another col for the post_id that was liked,
and a last col for for if the person who clicked like was logged in or not
to show how many anons or regular visitors liked the post.

That means everytime a post is loaded, a database call will be made to
query the table, grab all user_ids of for that post_id and run them through
a get_userinfo() or something right?   That seems resource intensive.


On Mon, Nov 11, 2013 at 10:47 AM, Gregory Lancaster <
greglancaster71 at gmail.com> wrote:

> Awesome answer, I was steering away from storing in a custom table because
> people tell me OFTEN that I should always try to make use of the built in
> wordpress meta fields available.  But this makes sense.
>
>
> On Mon, Nov 11, 2013 at 10:43 AM, Otto <otto at ottodestruct.com> wrote:
>
>> We implement plugin favorites on WordPress.org in a similar manner.
>>
>> The plugin directory is a bbPress installation, so plugin entries are
>> "topics". When a user favorites a plugin, the ID of that topic is saved to
>> their usermeta, and the ID of that user is saved to the topicmeta.
>>
>> The question is one of querying. We want to be able to show a user's
>> favorite plugins (so, get the usermeta, then get those topics), and we
>> potentially want to be able to show what users favorited a plugin as well
>> (so, get the topicmeta, then show those users). While we're not actually
>> doing the latter at the moment, it's a potential case, so there it is.
>> Reviews are even more complex, since they integrate three things: users, a
>> plugin or theme, and a post in the support forums.
>>
>> The problem you'll run into is one of making sure the data is synced
>> across
>> the two. What happens when your process craps out after adding the
>> usermeta, but before adding the postmeta? This isn't a problem on a small
>> scale, but when you build to large scale, it will happen eventually.
>>
>> In the long run, I think that we'll end up using a custom table for this,
>> in order to keep everything in a single location and to be able to query
>> by
>> either case. Meta isn't a great fit for connecting two entirely disparate
>> sets of data together with a many-to-many relationship. There really is no
>> proper many-to-many metaphor in WordPress, as such. You can do it with
>> taxonomy, but that way lies madness. ;)
>>
>> -Otto
>>
>>
>> -Otto
>>
>>
>> On Mon, Nov 11, 2013 at 12:16 PM, chriscct7 <hello at chriscct7.com> wrote:
>>
>> > Sounds like the best thing would be to store it in both places. Saves
>> two
>> > potentially expensive query's as your site scales up.
>> >
>> > -Chris
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> >
>> http://wordpress-hackers.1065353.n5.nabble.com/Like-Posts-Store-Data-in-DB-User-Meta-or-Post-Meta-tp42769p42772.html
>> > Sent from the Wordpress Hackers mailing list archive at Nabble.com.
>> > _______________________________________________
>> > wp-hackers mailing list
>> > wp-hackers at lists.automattic.com
>> > http://lists.automattic.com/mailman/listinfo/wp-hackers
>> >
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>
>