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!

È stato utile?

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

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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top