Suggerimenti per strutturare strutture JSON complesse?

Non sono un esperto di JS o di PHP quindi potrebbero esserci alcuni avvertimenti di cui non sono a conoscenza, ma queste sono alcune idee che mi vengono in mente quando vedo questo.

Per prima cosa, penso che la tua prima idea sia fantastica. Per rispondere ai punti che stai sollevando:

Is it okay to use the property "name" twice, since they are on different levels? I've read that it's better to keep the property names short for parsers. Therefore, should you use it twice? Or change them to "seg_name" and "dev_name", for example?

Se ho un tipo MyType e voglio memorizzarne il nome, mi aspetterei che fosse MyType.Name , non MyType.MyTypeName . In generale, una proprietà non dovrebbe preoccuparsi di ciò che è il suo genitore, è responsabilità del genitore.

In JSON, tutte le coppie chiave-valore devono essere circoscritte in modo che vi sia una differenza tra json["key1"].Name e json["key1"].Elements[0].Name in quanto queste sono due entità separate che vivono in nodi diversi. Nel caso in cui un parser non rispetti questo, è probabilmente truccato ben oltre ciò che è comunque accettabile.

Se solo il ragionamento fosse la velocità del parser, non credo che l'aggiunta di alcuni caratteri a una stringa farebbe molta differenza sull'altra mano.

You can see a clear pattern for "segments", "devices", and "scans" where they are each an array of objects.

Il modo corretto di modellare una relazione 1: N (cioè una segment ha N devices ) sta usando una raccolta, una matrice di oggetti in caso di JSON, quindi eri originariamente sulla traccia giusta.

Se volessi passare a tutti device s su un dato segment , preferirei farlo in un semplice ciclo di accesso ad array che controllare se device1 è definito su segment , quindi device2 è definito su segment , ...

Per quanto riguarda il nidificazione profonda, il problema con questo è presumibilmente la leggibilità umana. Questo può essere mitigato dividendo il json in sotto parti, i nodi figli nel codice corrente diventando le nuove radici.

Per riuscirci, potrebbe essere una buona idea pensare a come interrogare e inviare i dati invece di formattarli diversamente (o anche renderli mal strutturati). Considera questo scenario di comunicazione:

1. Query del client disponibili segments
2. Il server risponde con un elenco di segmentIds disponibile
3. Il client esegue una query su segment di segmentId
4. Il server risponde con i dati di segment che a loro volta contengono deviceIds

5. Il client esegue una query su device di segmentId e deviceId

   ...

Questo è ovviamente l'esatto opposto di quello che hai adesso, un ping-pong client-server molto pesante che sarebbe davvero inefficiente nel mondo reale.

Dipende da te prendere la decisione su come dovrebbe apparire ogni carico utile, considerando sia il numero di richieste per acquisire una quantità ragionevole di dati sia la dimensione dei dati in ciascuna risposta.

Ma questo mi sembra più un problema di architettura di rete, non proprio legato alla serializzazione su json, xml o binario.

Se si è veramente interessati alla larghezza dovuta alla nidificazione, non esiste uno standard accettato a livello globale. C'era un "limite" di larghezza di 80 caratteri nei primi tempi a causa delle dimensioni dello schermo del terminale. A parte i rigidi limiti hardware, non penso sia necessario attenersi ad alcuni numeri, forse circa 120-150 potrebbero essere una buona linea guida in questi giorni.

Tuttavia, lasciato ai tuoi valori in JSON è uno spazio vuoto senza senso, quindi se premi la scorciatoia di riduzione di un paio di volte, non succede niente di male. Dato che comunque il tuo JSON verrà gestito dai computer la maggior parte del tempo, penso che potresti eliminare del tutto il requisito di leggibilità di fronte a un buon design.