Vous pouvez faire du SQL direct pour avoir une seule requête pour les deux tables. Je vais fournir un exemple de requête aseptisée pour, espérons-le, empêcher les gens de placer des variables directement dans la chaîne elle-même (danger d'injection SQL), même si cet exemple n'en spécifie pas la nécessité:
@results = []
ActiveRecord::Base.connection.select_all(
ActiveRecord::Base.send(:sanitize_sql_array,
["... your SQL query goes here and ?, ?, ? are replaced...;", a, b, c])
).each do |record|
# instead of an array of hashes, you could put in a custom object with attributes
@results << {col_a_name: record["col_a_name"], col_b_name: record["col_b_name"], ...}
end
Edit : comme l'a dit Huy, un moyen simple est ActiveRecord::Base.connection.execute("...")
. Une autre façon est ActiveRecord::Base.connection.exec_query('...').rows
. Et vous pouvez utiliser des instructions préparées natives, par exemple si vous utilisez postgres, l'instruction préparée peut être effectuée avec raw_connection, prepare et exec_prepared comme décrit dans https://stackoverflow.com/a/13806512/178651
Vous pouvez également placer des fragments SQL bruts dans des requêtes relationnelles ActiveRecord: http://guides.rubyonrails.org/active_record_querying.html
et dans des associations, des étendues, etc. Vous pourriez probablement construire le même SQL avec des requêtes relationnelles ActiveRecord et faire des choses sympas avec ARel comme Ernie le mentionne dans http://erniemiller.org/2010/03/28/advanced-activerecord-3-queries-with-arel/ . Et, bien sûr, il existe d'autres ORM, des gemmes, etc.
Si cela va être beaucoup utilisé et que l'ajout d'index ne causera pas d'autres problèmes de performances / ressources, envisagez d'ajouter un index dans la base de données pour payment_details.created_at et pour payment_errors.created_at.
Si de nombreux enregistrements et pas tous les enregistrements doivent apparaître simultanément, envisagez d'utiliser la pagination:
Si vous devez paginer, envisagez de créer une vue dans la base de données appelée d'abord payment_records qui combine les tables payment_details et payment_errors, puis disposez d'un modèle pour la vue (qui sera en lecture seule). Certaines bases de données prennent en charge les vues matérialisées, ce qui peut être une bonne idée pour les performances.
Tenez également compte des spécifications du matériel ou de la machine virtuelle sur le serveur Rails et le serveur DB, la configuration, l'espace disque, la vitesse / latence du réseau / etc., la proximité, etc. .