Możesz wykonać bezpośredni SQL, aby mieć jedno zapytanie dla obu tabel. Podam przykład zdezynfekowanego zapytania, aby, mam nadzieję, powstrzymać ludzi przed wprowadzaniem zmiennych bezpośrednio do samego łańcucha (niebezpieczeństwo wstrzyknięcia SQL), nawet jeśli ten przykład nie określa potrzeby:
@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
Edycja : jak powiedział Huy, prosty sposób jest ActiveRecord::Base.connection.execute("...")
. Innym sposobem jest ActiveRecord::Base.connection.exec_query('...').rows
. I możesz używać natywnych przygotowanych instrukcji, np. Jeśli używasz postgres, przygotowaną instrukcję można wykonać za pomocą raw_connection, przygotuj i exec_prepared zgodnie z opisem w https://stackoverflow.com/a/13806512/178651
Możesz również umieszczać surowe fragmenty SQL w zapytaniach relacyjnych ActiveRecord: http://guides.rubyonrails.org/active_record_querying.html
oraz w powiązaniach, zakresach itp. Prawdopodobnie możesz zbudować ten sam SQL za pomocą zapytań relacyjnych ActiveRecord i możesz robić fajne rzeczy z ARel, jak wspomina Ernie w http://erniemiller.org/2010/03/28/advanced-activerecord-3-queries-with-arel/ . I oczywiście są inne ORM, klejnoty itp.
Jeśli będzie to często używane, a dodanie indeksów nie spowoduje innych problemów z wydajnością / zasobami, rozważ dodanie indeksu w DB dla payment_details.created_at i for payment_errors.created_at.
Jeśli wiele rekordów, a nie wszystkie, muszą pojawić się na raz, rozważ użycie podziału na strony:
Jeśli chcesz dokonać paginacji, rozważ utworzenie w DB najpierw widoku o nazwie payment_records, który łączy tabele payment_details i payment_errors, a następnie przygotuj model widoku (który będzie tylko do odczytu). Niektóre bazy danych obsługują zmaterializowane widoki, co może być dobrym pomysłem na wydajność.
Weź również pod uwagę specyfikację sprzętu lub maszyny wirtualnej na serwerze Rails i serwerze DB, konfiguracji, przestrzeni dyskowej, szybkości / opóźnieniu sieci / itp., Bliskości itp. I rozważ umieszczenie DB na innym serwerze / maszynie wirtualnej niż aplikacja Rails, jeśli nie masz, itp. .