계층 적 데이터를위한 플랫 또는 중첩 JSON?


12

나는 이미 ~ 5 번 앞뒤로 전환했습니다. 이 REST 엔드 포인트는 /api/tags/내부 용 (타사 클라이언트 없음)을위한 것이므로이 작업을 수행하는 유일한 사람입니다.

이 두 표현을 결정하고 있습니다.

플랫

{  
   "types":[  
      {  
         "id":1,
         "text":"Utility"
      },
      {  
         "id":7,
         "text":"Lease Terms"
      },
   ],
   "tags":[
      {  
         "id":8,
         "text":"Water",
         "type":1
      },
      {  
         "id":9,
         "text":"Electricity",
         "type":1
      },
      {  
         "id":5,
         "text":"Minimum 12 month lease",
         "type":7
      },
      {  
         "id":17,
         "text":"lease negotiable/flexible",
         "type":7
      },
   ]
}
  • 다소 모듈 식입니다. 호환성을 유지하면서 "국가"와 같은 다른 최상위 계층을 추가 할 수 있습니다.

중첩

{  
   "1":{  
      "text":"Utility",
      "tags":{  
         "8":{  
            "text":"Water"
         },
         "9":{  
            "text":"Electricity"
         },
      }
   },
   "2":{  
      "text":"Lease Terms",
      "tags":{  
         "5":{  
            "text":"Minimum 12 month lease"
         },
         "17":{  
            "text":"lease negotiable/flexible"
         },
      }
   },
}
  • 이미 사용 가능한 형식입니다. 사용하기 전에 데이터를 반복 할 필요가 없습니다.
  • 일부 대역폭을 절약합니다. gzip 이후에도 약간 작습니다.

어느 것을 사용해야합니까? 왜 그렇습니까? 이것이 개인적인 취향의 문제라면, 경험있는 개발자는 어떤 표현을 선호할까요?


Is this a matter of personal preference?. 나도 그렇게 생각해. 요구 사항> 요구 사항> 환경 설정
— Laiv

1
@Laiv이 경우 내 질문은 "경험이 풍부한 개발자가 어떤 표현을 선호하고 왜 표현합니까?"
— dvtan

이 ID는 시간이 지남에 따라 안정적이며 클라이언트가 나중에 기억하고 사용하기에 괜찮습니까? 아니면 로컬 메시지입니까?
— Erik Eidt 2016 년

@ErikEidt 이들은 영구 데이터베이스 기본 키입니다.
— dvtan

Water를 Utility의 하위 클래스로 생각하거나 Utility의 인스턴스로 생각하십니까?
— Erik Eidt 2016 년

답변:


8

사용 사례에 따라 다릅니다.

정적 형식의 언어와 함께 JSON을 사용할 때 구조가 형식에 매핑되면 큰 보너스가 있습니다. 즉, 키의 모든 이름을 미리 알고 있어야합니다.

따라서 Java를 사용하여 서비스를 사용하거나 JSON 스키마로 서비스를 문서화하려는 경우 1 위가 훨씬 깨끗합니다 (물론 두 가지 모두 작동 함).


4

더 이상의 맥락없이 말하기 어렵다. 나는 둘 다 함께 일했지만 점차적으로 # 1에 의지하기 시작했다. 일반적으로, 나는 단순함이 정교함보다 더 관련성이 있음을 발견했다.

# 1에서 엔티티와 관계는 명확하고 명백한 반면 # 2는 다른 사고 방식이 필요합니다. 어떤 사람들에게는 나무 (데이터 구조)가 그 자체를 설명하는 것이 아닙니다. Person> Address 보다 더 깊이있는 구성을 보지 못한 후배 개발자를 생각해보십시오 .

나는 다음과 같이 # 1을 읽을 수 있습니다 :

  • 유형이 지정된 태그 모음이 있습니다.

그러나 우리는 어떻게 # 2를 7 개 단어로만 설명 할 수 있습니까? 트리 구조에 익숙하지 않으면 # 2를 읽을 수 있습니다.

  • 태그에는 5와 17의 두 가지 속성이 있지만 그 유형을 모르겠습니다. 유형이 무엇이든, 하나의 속성 text가 있습니다.

# 2는 현명한 해결책이 될 수 있지만, 나는 영리함 (또는 효율성)에 대한 가독성을 불필요하게 희생하지 않을 것입니다.

이 답변을 쓸 때, 나는 응답이 # 2와 매우 유사한 타사 서비스와 통합되어야하는 프로젝트를 진행하고 있습니다. 이 서비스는 우리에게 달력을 제공합니다 : 년, 월, 일 및 시간

 { "2017" : { "01": { "01" : ["00:00", "01:00", "02:00"] } } } 

Java 개발자로서 서비스 응답의 직렬화 해제는 getters | setters | constructors를 통해 클래스에 직접 맵핑되지 않기 때문에 읽을 수있는 코드로 끝났습니다. 대신 문서 ( getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText 등)를 탐색하고 클래스의 계층 구조를 수동으로 채워야했습니다. 마지막으로 숫자 트리를 타임 스탬프 모음에 매핑했습니다! 어느 구조가 읽기 쉽고 역 직렬화가 더 쉬울까요? 당신이 클라이언트쪽에 있다면 어떤 것을 얻고 싶습니까?


1

다른 것을 원하지 않으면 다음을 사용할 수 있습니다.

{
    "Utility": {
        "8": "Water",
        "9": "Electricity"
     },
     "Lease Terms": {
        "5": "Minimum 12 month lease",
        "17": "lease negotiable/flexible"
     }
}

불행히도 여기서 JSON은 문자열을 키로 만 허용합니다.


또는 잠재적으로 "Utility": ["Water","Electricity"]등
— Caleth

그러나 당신은 그들을 참조 할 수 없습니다. 이 모든 것 뒤에는 수천 채의 집이 있고 각각 "8", "9", "5"를 포함하는 배열이 나올 것으로 기대합니다.
— gnasher729
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.