2013-07-18 18 views
5

Ho visto molte domande su questo argomento, ma nessuno di loro copre il mio caso.PHP con Spl DataStructures come sostituto per array multidimensionale

Sto costruendo un modulo ACL sulla base di 5 classi:

  1. ruolo
  2. Privilege
  3. Gruppo
  4. Wrapper (indovinate cosa fa ..) di fabbrica per il privilegio, il ruolo e Gruppo classi
  5. AccessList Archivia per i gruppi/ruoli (in base all'utilizzo e al caso)

Sto pensando di utilizzare SplQueue per archiviare i livelli di privilegi (principalmente per i privilegi ereditati). Pertanto, sto pensando di utilizzare un singolo oggetto per archiviare tutto e non pensare che la matrice multidimensionale normale sia la scelta migliore. Il flusso sarà come this paste, è TL; DR .. Ci scusiamo.

Quindi la mia domanda è la SplQueue essere un eccesso nel mio caso?

Devo utilizzare la Spl Data Structure alternativa e, in caso affermativo, quale?

EDIT Beh, io non poteva pensare ad un buon esempio di utilizzo, così lascia tenere la GBAC basato su UNIX.

+0

Una struttura dati deve supportare i casi d'uso per le operazioni che vengono eseguite su di esso. Non hai menzionato nessuno di loro. – Sven

+0

Bene lo scopo è generale, datemi un secondo per scriverlo e aggiornerò in un secondo –

+3

Penso che questo sia davvero eccessivo per i piccoli array. (il piccolo ha meno di 100-1000 elementi). L'hashmap interno fornisce per lo più un accesso abbastanza veloce. SPL è buono quando hai veramente bisogno di accedere (n) al log e inserire tempi, ecc. – bwoebi

risposta

4

Se si desidera memorizzare i dati nel modulo oggetto, utilizzare SplObjectStorage. SplQueue sarà eccessivo per un piccolo array.

SplQueue funziona su FIFO.

Quindi non si può accedere direttamente all'ultimo o vicino all'ultimo e ci vorrà del tempo.

Invece di SplQueue, suggerirò di utilizzare la matrice poiché è possibile accedere a qualsiasi elemento direttamente dall'indice di matrice.

È inoltre possibile controllare la risposta di questa domanda: Associative Array versus SplObjectStorage

Inoltre è possibile controllare la le prestazioni di SPLobjectStorage e la matrice, here is the code.

Per ulteriori read here.

SplObjectStorage decisamente scalato linearmente. Le prestazioni dell'array sono state meno prevedibili (deviazione standard maggiore) con set di dati più piccoli. E SplObjectStorage è davvero una soluzione migliore per la memorizzazione di molti oggetti in un set.

Quindi se i dati sono piccoli, è necessario utilizzare l'array altrimenti utilizzare lo SplObjectStorage per una grande quantità di dati.

+1

L'array presenta degli svantaggi se i dati diventano più grandi, per chiarire: 20 ruoli in totale, 6 gruppi e 1 identificativo di pagina (gli identificatori di pagina vengono utilizzati per determinare una parte specifica dell'app) 6x1 - Definizioni di gruppo e definizioni in-group * (6x1) x20 * (Almeno con la mia architettura/testa) che risultano in 120 definizioni nello storage che cresceranno drasticamente in 100 pagine app. Potrebbe esserci qualche svantaggio se vado con gli array o SplObjectStorage. Grazie! –

+0

@DaGhostmanDimitrov se si dispone di dati approssimativi di 120, è possibile utilizzare l'array e se si dispone di migliaia di record, utilizzare SplObjectStorage come ho aggiunto i collegamenti nella risposta. è possibile vedere i problemi di prestazioni arriveranno nell'array per i dati di grandi dimensioni e per i dati di piccole dimensioni le prestazioni di SplObjectStorage saranno negative rispetto all'array. ora dipende dai tuoi dati. –

+0

Consigli: quale approccio dovrei adottare? Usare gli array e rendere la struttura pronta per i dati bassi o dati avanzati (non si può pensare a parole migliori o dirle scusa, l'inglese non è il mio nativo) –

Problemi correlati