Parlate con tabelle in stile data warehouse con ActiveRecord?
-
10-07-2019 - |
Domanda
Man mano che la mia app Rails matura, diventa sempre più evidente che ha un forte sapore di data warehouse, manca solo una tabella dei fatti per rendere tutto esplicito.
Inoltre, ho appena letto i Capitoli 2 (Progettazione di bellissime API) e 3 (Mastering the Dynamic Toolkit) di Ruby Best pratiche .
Ora sto cercando di capire come progettare al meglio la parte di recupero dei fatti ...
Supponi di avere le seguenti dimensioni (modelli esistenti nell'app):
- Prodotto (contiene fondi)
- Fondo
- Misura (ad es. partecipazione totale, partecipazione media, esposizione media)
... e un buon vecchio fatto generale:
- Fatto (data, valore, più una colonna NULLable di chiave esterna per ciascuna delle mie dimensioni)
Alcuni aspetti su cui sarei grato di ricevere qualche consiglio:
- Cosa potrebbe costituire un'interfaccia di recupero flessibile?
- Cosa succede se ho Fatti con valori NULL (ovvero tutti, o non mi interessa) e NOT NULL (specifici) per una dimensione? Uno pseudo-valore come
: all
? O dovrebbe applicare una convenzione? - Come selezionare solo un sottoinsieme di valori di dimensione? O escludere un sottoinsieme? : only and: exclude?
- Qualcuno ha avuto esperienza con la creazione di
named_scope
per occuparsene? C'è l'ovvia attrazione di poter incatenarne una per ogni dimensione di interesse, ma diventa troppo goffa se arriviamo a 7 o 8 dimensioni?
(Sono consapevole che si ritiene che un plug-in act_as_fact
esiste in qualche modo (almeno, ci fu qualche piccolo ronzio a RailsConf 2006) ma non sono riuscito a trovare alcun codice o descrizione di come avrebbe potuto funzionare.)
Versioni: Rails, ActiveRecord 2.1.2, Oracle Enhanced Adapter 1.2.0
EDIT: ho guardato ActiveWarehouse e ho alcune riserve: - la filiale principale non ha commesso dal 08 novembre e nessuna attività è attiva dal gennaio 09; - il tutorial risale al 2006, è ammesso di essere obsoleto e 404 su di me; - sembra voler scappare da ActiveRecord - gran parte della mia app rimarrà in AR e al momento penso che voglio una soluzione AR.
Quindi mi starò alla larga da quello, grazie!
Soluzione 4
Quindi abbiamo un numero di gemme o plugin di vari gradi di complessità, nessuno dei quali sembra essere molto attivamente in fase di sviluppo (o c'è qualcosa che sta succedendo ma è sotto il radar).
In ogni caso, non sto cercando di costruire un data warehouse, ma solo di implementare una o due tabelle dei fatti in stile schema a stella. Ciò che chiedevo erano idee su come accedere a un tavolo del genere.
Mi sto proponendo di abbandonare l'idea di più livelli, in cui un aggregato attraverso una dimensione avrebbe un NULL nella chiave esterna per quella dimensione. Sebbene ridurrebbe il numero di righe coinvolte in una query, il vantaggio sarebbe piccolo e non gratuito: avrei una tabella dei fatti più ampia e un codice più complesso.
Il recupero sembra che potrebbe essere gestito con una serie di named_scopes
, uno per ogni dimensione, per il filtraggio. O un cercatore personalizzato, alimentato con un hash opportunamente costruito, potrebbe essere migliore.
Quando l'ho costruito, tornerò con alcune informazioni migliori ...
Altri suggerimenti
Cosa succede se ho dei fatti con entrambi NULL (ovvero tutto, o non importa) e NOT Valori NULL (specifici) per a dimensione? Uno pseudo-valore come: all? O dovrebbe applicare una convenzione?
NULL sarebbe un'offerta fuorviante perché non rappresenta alcuna associazione. Vorrei usare un valore come -1
(se si tratta di una chiave estera integer con solo valori > 0).
Come selezionare solo un sottoinsieme di valori di dimensione? O escludere un sottoinsieme?
with_scope()
potresti anche sovrascrivere la funzione find
def self.find(*args)
if anything
with_scope(a_scope) do
result = super *args
end
else
result = super *args
end
end
def self.a_scope
{:find => { :conditions => ["person_id = ?", me] , :readonly => true}}
end
Qualcuno ha avuto esperienza con la creazione di named_scopes da affrontare Questo? C'è l'ovvia attrazione di poter incatenarne uno per ciascuno dimensione di interesse, ma arriva troppo goffo se arriviamo a 7 o 8 dimensioni?
Abbiamo un database olap con 4 dimensioni e funziona bene. Penso che se implementerai alcuni metodi personalizzati per active_record, ti divertirai con la tua app.
Ho anche trovato questo: http://github.com/aeden/activewarehouse/tree/ master
ce n'è un altro che non ho usato, ma sembra buono:
http://github.com/wvanbergen/active_olap/tree/master
http://techblog.floorplanner.com/2008/ 29/07 / active-OLAP-released /
e questo per SOLR che ho trovato su Google
Stavo cercando di utilizzare ActiveWarehouse qualche tempo fa prima di venire a conoscenza di altre cose, quindi ho non posso dirti quanto funziona bene, ma è qualcosa da aggiungere al tuo elenco per il check-out. Ha generatori di fatti, dimensioni e cubi e un toolkit ETL.