CSV는 XML과 JSON의 좋은 대안입니까? [닫은]

가 CSV가 에 대한 좋은 옵션으로 간주 XML 및 JSON 언어 프로그래밍을?

일반적으로 XML 및 JSON (또는 일반 텍스트 파일)을 플랫 파일 저장소로 사용합니다. 그러나 최근에 PHP 에서 CSV 구현을 발견했습니다 . 나는 일반적으로 Excel 파일의 입력에 CSV가 사용되는 것을 보았지만 프로그래밍에는 사용하지 않았습니다. 어떤 식 으로든 XML이나 JSON보다 낫습니까?

그 대답은 다릅니다.

CSV는 특정 사용 사례에 적합합니다. 예를 들어, 큰 데이터 세트의 "스트리밍"형식으로 XML / JSON보다 스트리밍하기가 쉬우 며 CSV 파일은 저장 공간을 훨씬 적게 차지합니다. 다른 형식이 실용적이지 않은 기가 바이트 범위의 데이터 세트를 스트리밍하는 데 사용합니다.

또한입니다 정말 레거시 시스템과 워크 플로우를 처리 할 때 특정 산업에서 일반적인. JSON을 MS Excel로 가져옵니다.

ODI는 최근 2014 년을 "CSV의 해" 라고 부르며 CSV에 대해 언급했습니다.

"적절한"CSV 형식의 경우 HTTP 응답에 CSV MIME 유형 을 사용하십시오.

가장 확실하지 않습니다.

CSV는 데이터 세트 또는 기타 테이블 데이터에 매우 잘 매핑되는 테이블 형식입니다. 그러나 모든 데이터가 표 형식 인 것은 아닙니다! 가장 일반적으로 객체 그래프 를 직렬화하려고 합니다 . 다음과 같은 경우에 어려울 수 있습니다.

• 순환 참조
• 공유 된 하위 그래프 (예 : 둘 다 멤버와 동일한 객체를 포함하는 두 객체)
• 서로 다른 유형의 객체를 동일한 문서에 직렬화

또한 스토리지 형식에서 개체를 안정적으로 역 직렬화 할 수 있기를 원합니다.

XML

주로 확장 가능한 마크 업 언어입니다. 일반적인 데이터 구조를 저장하기 위해 구두를 can 수 있습니다. ID에 대한 언어 지원은 트리에 가장 적합하지만 복잡한 그래프를 만들 수 있음을 의미합니다. 사양에 대한 문서의 정확성을 테스트 할 수 있습니다. 이 형식에는 극단적 인 세부 표현과 같이 실용적이지 않을 수있는 다양한 문제가 있습니다.

JSON

주로 간단한 객체 트리 를 저장하는 방법 입니다. 일반 그래프는 지원하지 않습니다. JSON에는 primitives string , integer , float , boolean , null 및 컬렉션 유형 배열 및 객체 이외 의 유형 개념이 없습니다 .

YAML

JSON의 확장으로 가장 쉽게 이해됩니다. 임의 복잡도의 오브젝트 그래프를 작성할 수 있는 별명 개념이 있습니다. 올바른 입력에 사용할 수있는 태그 와 같은 메타 데이터 개념 이 있습니다.

CSV

단일 테이블을 제외하고는 아무것도 없습니다. 객체 그래프를 저장하려면 다음과 같은 스키마를 사용해야합니다.

#ID,Type,Field1,Field2,...,FieldN

1,String,foo
2,String,bar
3,Array<String>,1,2

구분 기호, 줄 종결 자, 인용 부호, 이스케이프 문자 및 일반 (이진) 데이터에 적합하지 않은 기타 여러 문제에 대해 동의하지 않는 많은 CSV 방언이 있습니다. 이로 인해 CSV 데이터를 처리하기가 다소 어려워집니다.

따라서 기본적으로 일반적인 직렬화 형식으로 CSV를 사용하는 경우 CSV를 사용하는 것이 쉽지 않거나 불가능합니다.

시간표 나 일련의 측정 값과 같은 표 형식의 데이터를 저장하는 데 사용할 때는이 비판이 적용되지 않습니다. 여기서 CSV (종종 탭으로 구분 된 값의 변형)는 일반적으로 다른 데이터 형식보다 더 작고 사용하기 쉽습니다.

또한 그것이 달성하려는 것에 달려 있다고 말해야합니다. 많은 문제의 경우 문제가 충분히 작고 선택이 기존 시스템과 잘 맞는다면 선택하는 것이 중요하지 않습니다.

레거시 시스템을 사용하고 새로운 형식으로 전환하려고 시도하는 경우 문제가 발생할 수 있습니다. 복잡성을 더 많이 도입하고 디버깅 할 새로운 입력 시스템이 있기 때문입니다. 나는 새로운 사람들이 존재하는 것과 다른 것을 선호하거나 새로운 형식이 나타나고 그것을 실험하고 싶을 때 이것을 많이 보았다. 이것은 좋은 생각 일 수도 있고 아닐 수도 있습니다. 상황에 따라 다릅니다.

몇 년 전 저는 다양한 형식의 CSV 파일에 의존하는 리서치 그래프 데이터베이스 시스템에서 일했습니다. CSV 파일 임포터는 우리를 위해 그래프를 작성하고 코드를 디버깅하고 최적화하기 위해 수년간의 작업을 수행했습니다. 빠르고 유연했으며 대규모 연구 프로젝트를 부트 스트랩하기 위해 행복하게 사용했습니다. XML이 등장했을 때 우리는 XML 임포터를 추가했지만 속도 나 표현 복잡성 측면에서 반드시 개선 된 것은 아니며, XML이 CSV보다 그래프 구조를 표현하는 데 더 나은 것은 아니 었습니다. JSON은 XML보다 훨씬 훌륭하고 간결하지만 여러면에서 비슷하므로 해당 시스템에서 새 가져 오기 도구를 만들 때 비슷한 결과를 기대합니다.

어느 시점에서 고객은 "코볼"형식으로 대량의 데이터를 가져 왔는데,이 줄에는 뒤에 오는 바이트를 해석하는 방법을 나타내는 마커가 포함 된 가변 길이의 줄이있는 파일이 있습니다. 스토리지가 비싸서 컴팩트 함이 요구 된 시점부터 시작되었습니다. 해당 데이터를 즉시 CSV 형식으로 변환하고 CSV 가져 오기 도구로 공급하여 해당 데이터를 가져 왔습니다. 그것은 쉬운 일이었고 디버깅과 유지 관리의 양을 최소화 시켰습니다. 이런 종류의 데이터를 항상 가져와야한다면 시스템에 직접 구축하여 성능과 효율성을 높일 수 있습니다.

따라서 수행중인 작업과 기본 시스템의 기능에 따라 다릅니다. 내 예에서 CSV 가져 오기 도구는 견고하게 설계되고 신뢰할 수 있습니다. 나는 내가 만들고있는 다른 레이어에서 무슨 일이 일어나고 있는지 이해하지 않고 하나의 형식이 더 좋거나 나쁘다는 것을 주저합니다. JSON을 좋아하고 선호하지만 특정 복잡한 데이터 구조와 충분한 데이터 세트가 주어지면 CSV 파일도 매우 잘 작동 할 수 있음을 알고 있습니다.

아니.

CSV는 실제로 단일 형식이 아닙니다. 이스케이프, 구분 기호 및 기타 많은 CSV 파일에 존재하는 다른 서식 문제에 대한 다양한 스타일이 있습니다.

이것을 플랫 파일 스토리지로 사용하려는 경우 JSON을 사용하면 훨씬 좋습니다. JSON은 CSV를 처리하는 것보다 번거 로움이 적은 객체와의 매핑을 수행합니다.

나는 그것에 대해 강력히 권할 것입니다. 어떤 시점에서 (사용자가 요청한 경우) CSV를 출력해도 괜찮습니다. 그러나 저장 / 가져 오기 목적에는 적합하지 않습니다. 이는 "CSV"가 매우 잘못 정의되어 있기 때문입니다. "C"는 "쉼표"또는 "문자"로 구분되어 표시됩니까? "와 같이 이스케이프 문자가 포함 된 텍스트 문자열을 어떻게 처리합니까? 모든 손상된 CSV 구현은 이스케이프 문자 등을 다르게 취급하므로 파일을 가져올 수는 있지만 가져올 수는 없습니다.

Excel은 좋은 데모입니다. 영어 버전에서는 ","를 구분 기호로 사용합니다. 독일에서는 ";"를 사용합니다. 그래서 독일어 버전은 영어 CSV 파일을 질식시키고 그 반대도 마찬가지입니다 ...

주요 강점은 인간의 가독성이며 할인해서는 안됩니다. 그러나 나는 그것을 스토리지 형식으로 의존하지 않을 것이며, 그 목적으로는 너무 취하기 쉽습니다. 사람을 위해 파일을 내 보내야하는 경우 CSV를 사용할 수도 있지만 xlsx 파일에 쓰는 라이브러리를 사용하려고 할 수도 있습니다 (무료로 사용할 수 있음).

일반적으로 NO. 왜? JSON과 XML은 기본적으로 두려운 CSV를 제거하기 위해 존재합니다. 그들은 오랫동안 CSV로 비정형 화 된 것에 대한 구조적 접근법입니다. 예, CSV가 여전히 선호되는 유스 케이스가 있지만 일반적으로 10 건 중 9 건은 CSV를 사용하지 않는 것이 좋습니다.