2009-06-26 13 views
5

La nostra azienda adora i rapporti che calcolano metriche oscure - metriche che non possono essere calcolate con i rilevatori di ActiveRecord (tranne find_by_sql) e dove le funzionalità basate su ruby ​​di ruport sono troppo lente.Quali sono le alternative a find_by_sql per query computazionali pesanti?

Esiste un plugin o un adattatore gem o db che eseguirà grandi calcoli nel livello del database? Qual è la tua soluzione per creare report complessi?

+0

Vedo che molte persone stanno visualizzando questa domanda, ma nessuno sembra voler mordere. C'è qualcosa che vieta alle persone di fare una pugnalata o due? – btelles

+0

Penso che la tua domanda sia un po 'vaga .. il concetto sembra molto divertente .. ma il tuo scenario specifico potrebbe non essere descritto abbastanza. –

+0

Secondo me c'è qualcosa di sbagliato nell'usare SQL per ottenere i tuoi report. Ricorda la regola dell'80-20 percento: ActiveRecord semplifica la risoluzione del tuo problema CRUD, l'altro 20 percento dipende da te. Inoltre, nella mia esperienza i report non hanno nulla a che fare con i modelli che usi nella tua applicazione. – Igor

risposta

0

Si potrebbe voler utilizzare DataMapper o Sequel per il proprio ORM se si rileva che ActiveRecord non ha l'espressività necessaria per query complesse. Passare da ActiveRecord non sarebbe una decisione da prendere probabilmente, ma potrebbe valere la pena di indagare almeno.

+0

Anche se al momento è un po 'troppo tardi nel nostro progetto per farlo, credo che questa sarà la nostra scelta. Non ho guardato molto in DataMapper, ma ho sentito molte grandi storie a riguardo. Grazie Pete! – btelles

1

plug Scoiattolo di Thoughtbot aggiunge un sacco di funzionalità Ruby-ish al metodo find di ActiveRecord, con condizionali multi-layered, varia, e le associazioni modello nidificati:

www.thoughtbot.com/projects/squirrel/

+0

Ottima idea! Abbiamo esaminato searchlogic e scoiattolo per generare istruzioni "where" in modo più efficace, ma il problema che stiamo riscontrando è con il calcolo dei valori tra più campi in una query ... Non sono sicuro che questi aiuteranno in questo particolare uso Astuccio. Ma fammi sapere se lo fanno! – btelles

1

Esiste qualcosa di inerente nei report che impedisce l'utilizzo di una visualizzazione SQL o di una stored procedure?

In un particolare progetto, una tecnica spesso trovo utile è quello di creare la query SQL (che può essere molto complessa) come una vista con nome nel database, e quindi utilizzare

YourModel.connection.select_all(query) 

a tirare indietro il dati. Non è un approccio ottimale; Sono desideroso di esplorare miglioramenti ad esso.

Sfortunatamente, come suggerito, il supporto per eseguire complessi report basati su database all'interno di binari sembra piuttosto limitato.

+0

Sì, il nostro negozio ha un guru SQL che vorrebbe davvero quell'opzione. E sembra un approccio pragmatico ... Non ho alcun problema con questo, tranne uno ... è un po 'difficile mantenere l'agnosticismo db quando creo delle migrazioni che includono stored procedure che sono specifiche per un tipo di database. Le viste sono sicuramente in palio però! Grazie per l'input, e mi dispiace per la risposta in ritardo! – btelles

2

Sebbene non sia indipendente dal database, la nostra soluzione è le funzioni di plpgsql dove diventa molto lento l'uso di Ruby e ActiveRecord.

+0

Sì, stiamo davvero cercando di restare con qualcosa che non è agnostico. Grazie per l'input però! – btelles

1

Sembra che le tabelle possano essere normalizzate. In un posto in cui ho lavorato, la quantità di normalizzazione che abbiamo fatto ha avuto un impatto sulle nostre esigenze di reporting, quindi abbiamo creato alcune tabelle ombra che contenevano un gruppo di dati aggregati e abbiamo segnalato ciò.

Sono d'accordo con il commento di Neil N che la domanda è un po 'vaga, ma forse questo ti spinge nella giusta direzione?

+0

Sì, la domanda è decisamente vaga. Ma la normalizzazione dei dati risolverebbe un problema leggermente diverso, e un'ulteriore normalizzazione dei nostri dati probabilmente rallenterebbe un po 'di più le query. Grazie per aver contribuito! – btelles

+0

Quello che intendevo era considerare la de-normalizzazione a scopo di reportistica. –

Problemi correlati