Generazione di array profondi: da superficiale a profondo, da profondo a superficiale o da cattiva idea?

5

Sto lavorando su una struttura di array che verrà utilizzata come origine dati per un modello di report in un'app Web.

I dati provengono da query SQL relativamente complesse che restituiscono una o più righe come array associativi monodimensionali. Nel caso di molti, vengono trasformati in array indicizzati bidimensionali.

I dati sono complessi e in alcuni casi ce ne sono molti. Per salvare i viaggi nel database (che sono estremamente costosi in questo scenario) sto tentando di ottenere tutti gli array di base (dati del database raw di 1 e 2 dimensioni) e inserirli, condizionatamente, in un singolo array di cinque livelli. Organizzare i dati in PHP sembra un'idea migliore che usare le istruzioni where in SQL.

Struttura matrice

    Array of years(
            year => array of types(
                            types => array of information(
                                                total => value,
                                                table => array of data(
                                                                index => db array
                                                                    )
                                                        )
                                )
                )

La mia prima domanda è, è una cattiva idea. Gli array di questo tipo sono appropriati per questa situazione?

Se ciò dovesse funzionare, come dovrei fare per popolarlo? Il mio pensiero iniziale era poco profondo e profondo, ma più lavoro su questo, più mi rendo conto che sarebbe molto difficile astrarre i condizionali che determinano dove ogni elemento va nell'array. Quindi sembra che partire dai dati più profondamente annidati potrebbe essere l'approccio che dovrei prendere.

Se si tratta di abuso di array, quali alternative esistono?

Modifica

Sono andato avanti con questo approccio, imparando e cambiando le cose mentre andavo. Ma ho finito con un array di finali simile. Ciò che ho imparato riguardo al profondo e profondo enigma è stato questo.

Sono andato nel processo pensando agli array esterni come il più grande di una serie di tazze, contenenti moltitudini di tazze più piccole che a loro volta contenevano un'altra moltitudine di tazze più piccole fino all'ultimo set che nella mia mente era acqua (essendo questo il matrice indicizzata dei valori del database). Gli array non sono tazze ...

L'idea si spaccò quando iniziai legittimamente a disegnare a mano le strutture dell'array e scoprii che la base di questi array, l'acqua piena di minuscole tazze che avevo immaginato, rappresentava un diavolo di molti più dati di quelle grandi tazze. Questo mi ha portato a vedere questi array profondamente annidati come torri, con i dati indicizzati che rappresentano una base di ordinamento, che si assottigliavano fino alla punta, che era l'array contenente.

Da lì, ho capito che il modo migliore per elaborare i dati era quello di raccogliere i dati di fondo, collegarli al livello successivo e poi risalire la torre collegando ogni livello al suo livello successivo.

Non sono sicuro se ho ragione, ma mi sento come se capissi gli array più ora di quanto facessi prima.

E sicuramente non sono ancora sicuro se questa è la soluzione migliore.

    
posta Will Meldon 21.11.2012 - 22:18
fonte

3 risposte

1

Non sono sicuro di aver capito il problema che stai cercando di risolvere. Puoi darci una query SQL di esempio?

  • Stai unendo cinque diverse tabelle usando 4+ relazioni per rendere una singola query? Se così fosse, ti consiglio di provare un ORM. Qualsiasi buona soluzione MVC per la tua lingua (ad es. CodeIgniter ) dovrebbe avere qualcosa per te.
  • Stai tentando di caricare l'intero contenuto di cinque tabelle in memoria (sul server PHP o sul client) in modo che tu possa unirti a loro una volta che l'utente seleziona qualcosa che descrive il join necessario? Se è così (e supponendo che non ci siano molti dati), potresti provare un ORM frontend basato su Javascript, magari usando qualcosa di semplice come Backbone. js .

Devo ammettere che non sono del tutto sicuro che entrambi i suggerimenti sopra riportati siano adatti al tuo problema come descritto. Mi piacerebbe un po 'più in dettaglio.

    
risposta data 04.12.2012 - 03:50
fonte
0

Come ridimensionate i vostri array interni? Immagino tu non sappia in anticipo le dimensioni per ognuno di loro.

Vedo tre possibili soluzioni:

  1. Se il database non viene modificato spesso, ma piuttosto letto, è possibile indicizzare le tabelle (internamente o con Lucene). Porterà più prestazioni.

  2. Usa un B-Tree, perché è anche amichevole rispetto allo "swapping" del disco rigido (suppongo che tu non voglia tenere tutto in memoria).

  3. una combinazione di 1 e 2.

risposta data 20.12.2012 - 12:01
fonte
0

Full-disclosure: provengo da più di un background JSON ma progettare con letterali e array di oggetti è praticamente lo stesso problema.

Progetterei con i seguenti obiettivi:

  • Crea sempre una struttura dati il più superficiale possibile fino a quando non inizi a duplicare inutilmente i valori ovunque (ad esagerare al punto in cui stai inutilmente duplicando interi set per chiavi / indie differenti). Le persone tendono a nidificare le cose per il solo scopo di nidificare o perché sembra che ci siano troppi oggetti in un set. Tutto ciò che conta è se tutto appartiene a una determinata categoria. Nota: con insiemi di dati più piccoli, a volte l'appiattimento di tutto per semplicità è una grande idea, ma questo non sembra uno di questi scenari.
  • Se l'ordinamento degli elementi non è critico e un set ha un valore univoco affidabile che è utile come chiave, convertirlo da indicizzato ad associativo con quel valore univoco come chiave. Ad esempio, non eseguire il loop di qualcosa e controllare il valore corretto se è possibile fare riferimento direttamente per nome. Ciò può ridurre drasticamente la complessità della tua funzionalità di accesso.
  • Il lato opposto preferisce indicizzato quando sono possibili più articoli senza un valore univoco affidabile o l'ordine in cui passerai attraverso questi elementi è importante (forse il secondo punto è meno critico in PHP).
  • Non formattare in modo condizionale. Quella cosa con 1D quando è solo un elemento o indicizzata in 2D quando è molti suona come una ricetta per logica senza senso per me. Il ciclo su un array di un elemento metà o addirittura il 75% del tempo è molto meno crufty / fragile.
risposta data 19.01.2013 - 20:14
fonte

Leggi altre domande sui tag