Non esitare a suggerire un nome o un modo migliore per spiegare questa domanda: non ero proprio sicuro di come chiamarlo.
La situazione è quella che potrebbe appena rientrare nella categoria "essere organizzati" ma spesso mi trovo a passare attorno a grossi blob di dati oa molti sotto-blob più piccoli (blob nel significato non tecnico della parola = o ), da utilizzare in varie parti delle mie app Web.
Ad esempio, creando un piccolo task manager che consente a qualcuno di creare un'attività che finisce per essere rappresentata in questo modo:
- Con titolo, data iniziale, utente, cliente, ecc. (attributi semplici).
- Zero o più espressioni temporali che rappresentano "pianificazioni" per quando l'attività deve essere eseguita - periodicamente, per giorno della settimana, per giorno del mese, ecc.
- Un elenco ad albero di attività secondarie che possono essere annidate a qualsiasi livello.
Questo è tutto abbastanza facile da rappresentare nel database con poche tabelle.
È anche abbastanza facile mettere in una serie di matrici e passare (ad esempio, passare una matrice di un modello di attività, attività secondarie e schedulare i dati tramite JSON a un oggetto jQuery che costruirà una lista di attività sul lato client.
Tra la creazione, l'aggiornamento, la visualizzazione, ecc., le attività, le liste di attività, ecc., ci sono un certo numero di luoghi in cui potrei trovarmi a passare una grande collezione di dati da un posto all'altro (specialmente lavorando con AJAX con molto elaborazione lato client), e spesso sembra più o meno la stessa cosa - solo un grande array che dice "ecco i dati per la tua attività e le 'cose' correlate".
Come puoi (o vorresti) mantenere questo organizzato? Ad esempio, di seguito è riportato un array che è stato estratto da un oggetto "Modello di attività" e che verrà passato tramite JSON a un oggetto JS che genererà e visualizzerà dinamicamente un elenco di attività sul lato client.
Suppongo che la domanda sia se e come definire la struttura di un tale "oggetto" al di fuori del database, del codice, ecc. e di come lo si documenta.
Ad esempio, mentre le sottoattività nidificate sono piuttosto esplicative (e dati duplicati, disponibili solo per comodità), non è immediatamente evidente che la matrice "SubTasks" DEVE avere ciascuna attività secondaria visualizzata nell'array AFTER (indice superiore a) è genitore sottotask e BEFORE (cioè: con indice inferiore a) qualsiasi sottoattività secondaria, in modo che possano essere elaborati in ordine con la certezza che ogni attività secondaria può essere aggiunta alla sua attività secondaria già esistente.
Ci sono un certo numero di regole come questa qui, e se una matrice "relativamente" simile è usata in 9 posti diversi, documentando in commenti / documentazione di classe, ecc. finisce per succhiare.
[43] => Array
(
[Meta] => Array
(
[SubTaskCount] => 6
[TemporalExpressionCount] => 3
[NumInstances] => 0
[OutOfSync] => 0
)
[Fields] => Array
(
[UserID] => 1
[ClientID] => 1
[StatusID] => 1
[Title] => Keep Testing
[Body] => How are you? Because I am a potato.
[UserName] => Wheatley
[ClientName] => Wheatley Laboratories
[BodyHTML] => Etc.
)
[Sched] => Array
(
[TemporalExpressions] => Array
(
[0] => Array // Every Monday every month
(
[type] => dw
[ExpressionID] => 1
[ord] => 0
[day] => 1
[month] => 0
)
[1] => Array // Every Tuesday every month
(
[type] => dw
[ExpressionID] => 2
[ord] => 0
[day] => 3
[month] => 0
)
[2] => Array // The last of every month
(
[type] => dm
[ExpressionID] => 3
[day] => -1
[month] => 0
)
)
[TaskInstances] => Array
(
// This would have data on "complete" status of tasks by date...
)
[InitialDate] => 2011-12-02
[DueTime] => 14:55:00
[SchedDates] => Array
(
[1322812800] => 2011-12-02
[1323072000] => 2011-12-05
[1323244800] => 2011-12-07
[1323417600] => 2011-12-09
[1323676800] => 2011-12-12
// ... List of dates between externally defined date range parameters...
)
)
[SubTasks] => Array
(
[1355] => Array
(
[SubTaskID] => 1355
[ParentST] =>
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1356] => Array
(
[SubTaskID] => 1356
[ParentST] => 1355
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1357] => Array
(
[SubTaskID] => 1357
[ParentST] => 1355
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1358] => Array
(
[SubTaskID] => 1358
[ParentST] => 1355
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1359] => Array
(
[SubTaskID] => 1359
[ParentST] =>
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1360] => Array
(
[SubTaskID] => 1360
[ParentST] =>
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
)
[SubTasksNested] => Array
(
[1360] => Array
(
[SubTaskID] => 1360
[ParentST] =>
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1359] => Array
(
[SubTaskID] => 1359
[ParentST] =>
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1355] => Array
(
[SubTaskID] => 1355
[ParentST] =>
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
[SubTasks] => Array
(
[1358] => Array
(
[SubTaskID] => 1358
[ParentST] => 1355
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1357] => Array
(
[SubTaskID] => 1357
[ParentST] => 1355
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
[1356] => Array
(
[SubTaskID] => 1356
[ParentST] => 1355
[RootT] => 43
[UserID] => 1
[Title] => New Subtask Title
[Body] =>
[DueDiff] => 0
[UserName] => Eli
)
)
)
)
[TemplateID] => 43
)