Anda bisa melakukan SQL langsung untuk memiliki satu permintaan untuk kedua tabel. Saya akan memberikan contoh kueri yang disanitasi agar mudah-mudahan orang tidak menempatkan variabel langsung ke dalam string itu sendiri (bahaya injeksi SQL), meskipun contoh ini tidak menentukan kebutuhan untuk itu:
@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
Sunting : seperti kata Huy, cara sederhana adalah ActiveRecord::Base.connection.execute("...")
. Cara lain adalah ActiveRecord::Base.connection.exec_query('...').rows
. Dan Anda dapat menggunakan pernyataan siap asli, misalnya jika menggunakan postgres, pernyataan siap dapat dilakukan dengan raw_connection, mempersiapkan, dan exec_prepared seperti yang dijelaskan dalam https://stackoverflow.com/a/13806512/178651
Anda juga dapat memasukkan fragmen SQL mentah ke dalam kueri relasional ActiveRecord: http://guides.rubyonrails.org/active_record_querying.html
dan dalam asosiasi, cakupan, dll. Anda mungkin dapat membangun SQL yang sama dengan kueri relasional ActiveRecord dan dapat melakukan hal-hal keren dengan ARel sebagai Ernie menyebutkan di http://erniemiller.org/2010/03/28/advanced-activerecord-3-queries-with-arel/ . Dan, tentu saja ada ORM lain, permata, dll.
Jika ini akan banyak digunakan dan menambahkan indeks tidak akan menyebabkan masalah kinerja / sumber daya lainnya, pertimbangkan untuk menambahkan indeks dalam DB untuk payment_details.created_at dan untuk payment_errors.created_at.
Jika banyak catatan dan tidak semua catatan perlu muncul sekaligus, pertimbangkan untuk menggunakan pagination:
Jika Anda perlu membuat paginasi, pertimbangkan untuk membuat tampilan dalam DB pertama yang disebut payment_records yang menggabungkan tabel payment_details dan payment_errors, kemudian miliki model untuk tampilan (yang akan hanya-baca). Beberapa DB mendukung pandangan terwujud, yang mungkin merupakan ide bagus untuk kinerja.
Juga pertimbangkan spesifikasi perangkat keras atau VM pada server Rails dan server DB, konfigurasi, ruang disk, kecepatan jaringan / latensi / dll., Kedekatan, dll. Dan pertimbangkan untuk menempatkan DB pada server / VM yang berbeda dari aplikasi Rails jika Anda belum, dll. .