Trovare un modo per semplificare le query complesse sull'applicazione legacy

2

Sto lavorando con un'applicazione esistente basata su Rails 3.1 / MySql con gran parte del lavoro svolto in un'interfaccia JavaScript, anche se le piattaforme effettive non sono tremendamente rilevanti qui, tranne che forniscono contesto.

L'applicazione è potente, gestisce una quantità ragionevole di dati e funziona bene. Poiché il numero di clienti che lo utilizzano e la complessità dei progetti che creano aumentano, tuttavia, stiamo iniziando a riscontrare alcuni problemi di prestazioni. Per quanto ne so, la fonte di questi problemi è che i dati rappresentano un albero ed è molto difficile per ActiveRecord sapere in modo deterministico quali dati deve essere recuperato.

Il mio modello ha molte relazioni come questa:

Project
   has_many Nodes
   has_many GlobalConditions

Node 
   has_one Parent
   has_many Nodes
   has_many WeightingFactors through NodeFactors
   has_many Tags through NodeTags

GlobalCondition
   has_many Nodes ( referenced by Id, rather than replicating tree )

WeightingFactor
   has_many Nodes through NodeFactors

Tag
   has_many Nodes through NodeTags

L'intero sistema ha qualcosa nella regione di trenta tipi che opzionalmente bloccano uno o più nodi nell'albero.

La mia domanda è: cosa posso fare per recuperare e costruire questi dati più velocemente?

Avendo lavorato molto con .Net, se mi trovassi in una situazione simile, avrei cercato di creare una stored procedure per estrarre tutto dal database in una volta sola, ma preferirei mantenere la mia logica nell'applicazione e da quello che posso dire sarebbe difficile prendere i dati interrogati e creare oggetti ActiveRecord da esso senza perdere la loro integrità, il che causerebbe più problemi di quanti ne risolva.

Mi è anche venuto in mente che potevo raggruppare i dati e inviarli in modo asincrono, il che non migliorerebbe le prestazioni ma migliorerebbe la percezione delle prestazioni da parte degli utenti. Tuttavia se le sezioni dei dati sono comparse dopo il caricamento della pagina potrebbe anche essere abbastanza confuso.

Mi chiedo se sarebbe una strategia utile per rendere tutto consapevole del suo progetto padre, in modo che uno possa tirare tutti i record per quel progetto e quindi costruire le relazioni in seguito, ma data l'ubiquità di alberi complessi nella giornata giorno di programmazione della vita non sarei sorpreso se ci fossero alcuni schemi di progettazione migliori o approcci standard a questo tipo di situazione in cui non sono esperto.

    
posta glenatron 20.08.2014 - 14:16
fonte

1 risposta

1

whether it would be a useful strategy to make everything aware of it's parent project

Che è una strategia standard. Si chiama " denormalizzazione ". Presunto

  • i tuoi "elementi del progetto" non cambiano mai il progetto a cui appartengono
  • la chiave ID principale del tuo progetto non cambierà mai
  • la memoria aggiuntiva necessaria per gli ID non è un problema
  • risolve effettivamente i tuoi problemi di prestazioni

dovresti applicarlo.

Un altro approccio sta tentando di aggiungere alcune viste al tuo database, incapsulando alcune operazioni JOIN complesse (presumo che il tuo database sia correttamente indicizzato in modo che lo stesso JOIN non rallenti le cose più del necessario). Non ho mai usato Rails da mayself, ma AFAIK ActiveRecord funzionerà sulle visualizzazioni. Quindi, ad esempio, unendo insieme 2 tabelle di una relazione padre-figlio, invece di avere un primo SELECT SQL per determinare un set di oggetti padre e un elenco di SELECT SQL, ognuna per l'insieme di oggetti figlio di uno specifico ID padre , si estrae tutti i dati dalla visualizzazione unita con un solo SQL selezionato. Ovviamente, questo funzionerà meglio quando hai bisogno dei dati in forma unita e non vuoi scrivere modifiche al tuo sistema DB.

    
risposta data 22.08.2014 - 13:02
fonte

Leggi altre domande sui tag