1

les rails 5 rails g migration create_foo_bar_join_table commande génère la migration suivante:Justification de rails 5 Se table générée par défaut

class CreateFooBarJoinTable < ActiveRecord::Migration[5.0] def change create_join_table :foos, :bars do |t| # t.index [:foo_id, :bar_id] # t.index [:bar_id, :foo_id] end end end

Pourquoi le talon du générateur sur deux indices (bidirectionnel) avec des clés composites? Aussi pourquoi sont-ils commentés? Je suis confus par ceci et ne peux pas trouver une explication claire pour avoir ces défauts suggérés.

Les indices ci-dessus sont-ils plus efficaces que ceux ci-dessous? ... create_join_table :foos, :bars do |t| t.index :foo_id t.index :bar_id end ...

+0

Je n'ai pas eu l'occasion de se pencher sur cette profonde, peut-être vous avez déjà pris un coup d'oeil à https://github.com/rails/rails/blob/master/activerecord/lib /rails/generators/active_record/migration/templates/migration.rb#L25 pour plus d'informations? – lshepstone

+0

Semble que les index composites sont spécifiquement pour MySQL. Bon à savoir. – jusko

Répondre

1

sur la réponse Nous sommes tombés exactement à lire la documentation sur has_and_belongs_to_many:

Il est aussi une bonne idée d'ajouter des index à chacune de ces colonnes pour accélérer le processus joint. Cependant, dans MySQL, il est conseillé d'ajouter un index composé pour les deux colonnes car MySQL n'utilise qu'un index par table lors de la recherche.

https://apidock.com/rails/ActiveRecord/Associations/ClassMethods/has_and_belongs_to_many