Customize deals app's homepage and emails thanks to user history: how to do it the right way on Rails/postgreSQL?

问题

I’d like to customize :

1. The order of the deals on the homepage
2. Emails depending on the deals a user has seen.

Thanks to people on SO, it seems that the best would be to have 3 models and tables "standard_user", "deals" and "deals_participation" in order to have the many-to-many relationships the app need, a link table with to as follows:

class DealParticipation < ActiveRecord:Base
#This means the deal_participations table has a standard_user_id key
belongs_to :standard_user
#This means the deal_participations table has a deal_id key
belongs_to :deal
#... more logic goes here ...
end

class StandardUser < ActiveRecord::Base
has_many :deal_participations
has_many :deals, :through => :deal_participations
# ... more logic goes here ...
end

class Deal < ActiveRecord::Base
has_many :deal_participations
has_many :standard_users, :through => :deal_participations
belongs_to :admin_user
#... more logic goes here ...
end

Where I’m lost is : how should I store and which table should I query the data of which deals a certain user has participated in:

should I store this deals_participation_table ? Its columns being deals_participation_id/user_id/deals_id, I fear that the deals_participation table will be highly ineffective to query as I will have to search an enormous number of lines, to find where user = Mathieu45 (example) then find the corresponding deals and make some sort of calculation to know which kind of deals he’s interested in and then use that info to adjust the deals list on the homepage (and emails sent to him).
should I instead store it in the users_table itself to have direct access based on the user_id to the deals he did ?
store it in another table dedicated to user_history ?

回答1:

The schema you've described will be very efficient for the kind of query you're interested in, provided you put the correct indices on your tables. Databases don't behave like lists: asking the question "Which deals did XXX participate in" shouldn't scan the whole table, because a correctly indexed table will know exactly where to find all of XXX's deals.

In order to get this set up correctly, here's what your migrations will look like:

class CreateStandardUsers < ActiveRecord::Migration
  def change
    create_table :standard_users do |t|
      t.string :name
      t.timestamps
      # More fields go here
    end

    add_index :standard_users, :name
  end
end

class CreateDeals < ActiveRecord::Migration
  def change
    create_table :deals do |t|
      t.references :admin_user
      # other fields go here
    end

    add_index :deals, :admin_user_id
    # other indices go here... anything you want to search on efficiently.
  end
end

class CreateDealParticipations < ActiveRecord::Migration
  def change
    create_table :deal_participations do |t|
      t.references :standard_user
      t.references :deal

      t.timestamps
    end

    add_index :deal_participations, :standard_user_id
    add_index :deal_participations, :deal_id
    add_index :deal_participations, :created_at
  end
end

There's still lots more that belongs in these migrations (e.g. you should add non-null constraints, uniqueness constraints, etc). But the point is that having these indices makes the database operations you're describing extremely fast.

来源：https://stackoverflow.com/questions/16215150/customize-deals-apps-homepage-and-emails-thanks-to-user-history-how-to-do-it-t

标签

mysql

ruby-on-rails

ruby-on-rails-3

postgresql