È possibile eseguire l'SQL diretto per avere una singola query per entrambe le tabelle. Fornirò un esempio di query igienizzato per impedire alle persone di inserire le variabili direttamente nella stringa stessa (pericolo di iniezione SQL), anche se questo esempio non ne specifica la necessità:
@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
Modifica : come ha detto Huy, un modo semplice è ActiveRecord::Base.connection.execute("...")
. Un altro modo è ActiveRecord::Base.connection.exec_query('...').rows
. E puoi usare istruzioni preparate native, ad es. Se usi postgres, le istruzioni preparate possono essere fatte con raw_connection, preparazione ed exec_prepared come descritto in https://stackoverflow.com/a/13806512/178651
Puoi anche inserire frammenti SQL grezzi nelle query relazionali di ActiveRecord: http://guides.rubyonrails.org/active_record_querying.html
e in associazioni, ambiti, ecc. Probabilmente potresti costruire lo stesso SQL con le query relazionali di ActiveRecord e fare cose interessanti con ARel come menziona Ernie in http://erniemiller.org/2010/03/28/advanced-activerecord-3-queries-with-arel/ . E, naturalmente, ci sono altri ORM, gemme, ecc.
Se questo verrà utilizzato molto e l'aggiunta di indici non causerà altri problemi di prestazioni / risorse, prendere in considerazione l'aggiunta di un indice nel DB per payment_details.created_at e per payment_errors.created_at.
Se molti record e non tutti i record devono essere visualizzati contemporaneamente, considera l'utilizzo dell'impaginazione:
Se è necessario impaginare, prendere in considerazione la creazione di una vista nel DB prima chiamata payment_records che combina le tabelle payment_details e payment_errors, quindi disporre di un modello per la vista (che sarà di sola lettura). Alcuni DB supportano viste materializzate, che potrebbero essere una buona idea per le prestazioni.
Considera anche le specifiche hardware o VM sul server Rails e sul server DB, sulla configurazione, sullo spazio su disco, sulla velocità / latenza / ecc. Della rete, sulla vicinanza, ecc. .