[buddypress-trac] [BuddyPress Trac] #5644: Activity Favorites: alternative management & new features

[buddypress-trac]

#5644: Activity Favorites: alternative management & new features
-----------------------------------+------------------
 Reporter:  imath                  |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  2.1
Component:  Activity               |     Version:  2.0
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------

Comment (by boonebgorges):

 Cool idea. I definitely agree that this kind of functionality is sorely
 missing from activity favorites.

 My most serious concern is about scaling. Say you have a site with 1000
 users. It's not too hard to imagine your activity table having 1,000,000
 rows after some use. Then let's say people start using activity favoriting
 fairly regularly (especially since it'd become so much more useful). It's
 easy to imagine tens or hundreds of thousands of rows being added to
 activitymeta. The nature of the activitymeta table (and meta_query in
 general) means that queries against the data are going to be very slow
 (especially the `=` query). Multiply by 20 within a single activity query
 loop. And this is on a relatively small site with fairly modest numbers.

 Activity favorites are many-to-many relationships, and are ideally best
 represented with a proper relationship table. The schema would be
 something like:

 {{{
 id bigint(20) AUTO_INCREMENT PRIMARY KEY,
 activity_id bigint(20),
 user_id bigint(20)
 }}}

 with indexes on each column (and maybe a date column too).

 Before moving forward too much with your suggestion, I'd like to see some
 real data. imath, maybe you can write a new command for
 https://github.com/boonebgorges/wp-cli-buddypress/ for generating activity
 favorites. Then, generate a ton of data on your proposed schema. Then,
 whip up a table like I'm suggesting and generate a ton of data on *that*
 schema. Then, run some numbers to see what the differences are like at
 scale for the various kinds of queries that you'll be running. I have a
 feeling the differences are going to be very significant - especially as
 the activitymeta table gets larger (think about the extra stuff we're
 storing in there these days - `'post_title'`, etc).

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5644#comment:1>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac