키 값 쌍에 사용할 JSON 구조는 무엇입니까?


23

키 값 쌍에 어떤 JSON 형식이 더 적합합니까? 그 이유는 무엇입니까?

[{"key1": "value1"}, {"key2": "value2"}]

또는:

[{"Name": "key1", "Value": "value1"}, {"Name": "key2", "Value": "value2"}]

또는:

{"key1": "value1", "key2": "value2"}

첫 번째 변형은 더 작고 "의미 적으로 의미있는"것으로 보입니다. 두 번째 변형은보다 균일하게 구성되어 처리에 도움이 될 수 있습니다. 세 번째 변형은 훨씬 더 의미 론적으로 보입니다.

키 값 쌍은 임의의 데이터를 다른 항목에 첨부하는 데 사용됩니다. 시스템을 통해 데이터를 정리하려면 데이터를 JSON으로 직렬화해야합니다.


3
주문이 필요하지 않은 한, 왜 고려하지 {"key1": "value1", "key2": "value2"}않겠습니까?
kennytm

4
JSON은 이미 (중첩 가능) 사전입니다.
Kasey Speakman 2016 년

1
귀하의 문제는 설명이 이러한 형식 중 하나가 작동한다고 말할 정도로 충분히 넓으며, 실제 질문은 고객이 사용하는 기술에 따라 소비를 단순화하는 방법입니다.
scriptin

당신은 당신의 요구를 충족시키는 가장 간단한 것을 사용해야하며, 그것이 단순한 객체 형태 (# 3)가 되길 바랍니다. 그러나 더 많은 옵션을 찾으려면 키와 값에 각각 하나씩 두 개의 배열을 병렬로 사용할 수 있습니다. 객체 키 및 중복 키 (# 3에서는 지원되지 않음)를 계속 지원하면서 가능한 한 컴팩트합니다.
Erik Eidt 2016 년

답변:


10

첫 번째 또는 세 번째 옵션을 선택할지 여부는 사용 사례에 따라 다릅니다. 동일한 유형의 사물을 여러 가지 다른 인스턴스로 모델링하는 경우 첫 번째를 선택하십시오. 예를 들어 사람 목록이 있습니다. 한 가지 속성을 여러 가지로 모델링하는 경우 세 번째 속성을 선택하십시오. 첫 번째 형식에서는 키를 반복 할 수 있지만 세 번째 형식에서는 키를 반복 할 수 없습니다.

두 번째 옵션은 끔찍하며 아직 적절한 사용 사례를 찾지 못했습니다. 더 장황한 것 외에도 끔찍한 이유는 단일 수준 JSON의 경우 대부분의 라이브러리가 사전 /지도로 자동 변환하지 않기 때문입니다. 깊이 중첩 된 JSON의 경우 XPath와 유사한 쿼리 인터페이스 가 중단 됩니다.

이것은 작업하기가 어렵습니다. 컴파일 타임에 키를 모르는 경우 키를 클래스로 변환 할 수 없으므로 사전 또는 XPath 인터페이스가 필요합니다. 지금은 큰 문제가 아닌 것 같지만 데이터 형식이 길수록 변경하기가 더 어려워집니다.


5
두 번째 옵션의 가장 큰 장점은 문자열이 아닌 키, 특히 복합 키와 함께 작동한다는 것입니다.
코드 InChaos

1
두 번째 옵션은 끔찍하지만 아직 사용 사례를 찾지 못했습니까? 키 / 값 쌍이 많은 사전 배열은 여러 객체를 전송하기위한 가장 일반적인 형식이어야합니다.
gnasher729 2016 년

2
@ gnasher729, 가장 일반적인 형식의 경우 실제 키는 모두 왼쪽에 [{"key1": "value1", "key2": "value2"}]있습니다.. 두 번째 형식은 실제 키를 오른쪽에 배치하고 "이름"이라는 다른 키를 사용하여 실제 키를 가리 키므로 표준 도구로 구문 분석하기가 매우 어렵습니다.
Karl Bielefeldt

그 중 하나 인 @CodesInChaos를 알려 드리겠습니다. 그럼에도 불구하고, 그것은 매우 특별한 경우 여야합니다. 나는 야생에서 그것을 필요로 본 적이 없다.
Karl Bielefeldt

3
미안하지만 이것은 나쁜 대답입니다. 두 번째 옵션은 매우 일반적으로 사용 및 권장됩니다. 키 유연성을 제공하고 소비자를 방해하지 않으면 서 더 많은 값 / 메타 데이터 필드로 확장 할 수 있으며 요소 순서를 유지할 수 있습니다. 또한 주어진 이유는 가짜입니다. "자동 변환"을 깨뜨리지 않으며 (작성자의 프레젠테이션을 배열로 간주하기 만 함) XPath와 같은 쿼리 인터페이스에서 잘 작동합니다. 유일한 단점은 증가 된 상세도입니다.
Hejazzman

5

세 번째 형식은 일반적 으로 최고입니다. 그러나 다음은 첫 번째 형식에 적합한 예입니다.

[{
  "username": "foo",
  "id": 1
}, {
  "username": "bar",
  "id": 2
}, {
  "username": "baz",
  "id": 3
}]

여기서 각 객체는 별도의 것을 의미합니다 (각 객체는 다른 것과 동일한 키를 사용하므로 병합 할 수 없습니다). 그러나 목록의 각 객체는 1) 더 짧고 2) 사용자 이름과 ID를 가진 것이 아니라 사용자 이름과 ID를 가진 것을 참조하기 때문에 { "username": "foo", "id": 1 }오히려 저장됩니다 [{ "username": "foo" }, { "id": 1 }].

두 번째 옵션의 문제점은 JSON과 함께 작동하는 것이 장황하다는 것입니다. 그러나 속성에 대한 메타 정보를 저장해야하는 경우 사용할 수 있습니다. 예를 들면 :

{
  "key": "foo",
  "value": 1,
  "mutable": true
}

여기 mutable에서는 부모 개체가 아닌 속성 자체를 수정할 수 있는지에 대한 가상의 경우를 나타냅니다. 이와 같은 메타 정보 Object.defineProperty는 속성에 대한 "구성 가능", "열거 가능"및 "쓰기 가능"정보를 저장 하는 JavaScript와 유사 합니다.


C # REST 엔드 포인트로 보내는 일부 JSON에 대해 첫 번째 형식을 사용하려고 시도했지만 사전 객체로 변환하지 않았습니다. 그것을 세 번째 형식으로 변환하면 정리되었습니다.
fizch

5

이것들은 키 / 값 쌍이라고 말합니다. 이 경우 # 3 : 키 / 값 쌍 사전을 사용하십시오.

키 / 값 쌍이 아닌 경우 "키"및 "값"이라고 부르지 말고 임의의 내용이 포함 된 사전 배열 인 # 2를 사용하십시오.

키 / 값 쌍뿐만 아니라 순서도 필요하지 않은 경우 구조 # 1은 멍청합니다. 당신이 거의하지 않습니다.


3

json을받는 사람의 신발에 자신을 넣으십시오. 키 이름을 모르는 경우 첫 번째 또는 마지막 형식으로 키 이름을 어떻게 검색합니까? 물론 json을 반복 할 수는 있지만 세 가지 형식 모두 동일한 결과를 얻으므로 구문의 문제 일뿐입니다. 나는 이것이 의미있는 유일한 질문이라고 생각합니다. 키 이름을 알고 있다면 첫 번째 또는 마지막 옵션이 더 간결하고 두 번째 선택이 더 이해하기 쉽지 않은 경우 더 작습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.