Вот усовершенствование логики без потери смысла:
var customers = [
{
"ID" : "client ABC",
"cluster" : { "ID": "cluster 123", "flights": 4, "profit": 5245, "clv": 2364 },
"segment" : { "ID": "segment 456", "flights": 2, "profit": 2150, "clv": 1564 },
"node" : { "xpos" : 1, "ypos" : 2 }
}, {
"ID" : "client DEF",
"cluster" : { "ID": "cluster 789", "flights": 4, "profit": 5245, "clv": 2364 },
"segment" : { "ID": "segment 876", "flights": 2, "profit": 2150, "clv": 1564 },
"node" : { "xpos" : 1, "ypos" : 2 }
}
];
В приведенном выше фактическом «уровне»:
clusters > flights etc & segments > flights etc & nodes > xpos etc
, что также может быть написано:
level 1: clusters
level 2: flights, profit, & clv (note: values are unique from segments tho labels are identical)
level 1: segments
level 2: flights, profit, & clv
level 1: nodes
level 2: xpos & ypos
Хорошо, давайте согласимся, что пример OP (как изначально написано) может соответствовать строгим механическим требованиям спецификации JSON.
Однако ОП описывает 3 «уровня», иллюстрируя их как кластер> сегмент> узел. Слово «уровень» и стрелки имеют смысл только в том случае, если между этими объектами существует семантическая связь. В конце концов, «уровни» должны относиться друг к другу в иерархии, наследовании, последовательности или каким-либо подобным образом наслоенным образом.
Исходный пример не дает намека на связь между какой-либо частью кластера и любой частью сегмента или любой частью узла; это не дает никакой возможности угадать, какими должны быть отношения. В этом примере метки располагаются рядом друг с другом с несколькими посторонними скобками вокруг них.
Без очевидного отношения к кодированию каждый из этих ключей логически называет уникальное свойство объекта «клиент», то есть каждый клиент имеет кластеры, сегменты и узлы. Каждое свойство четко обозначено, и каждое может счастливо сосуществовать в плоской структуре. Если у ОП есть больше информации об отношениях, которые требуют уровней, структуру легко изменить.
Короче говоря, вложение должно иметь смысловую цель; если это не так, маркеры вложения должны быть опущены. Как представлено, большая часть синтаксиса JSON в примере OP не имела очевидного значения и вводит логические проблемы. Пересмотр разрешает эти проблемы, насколько это возможно, с учетом информации.