Является ли CSV хорошей альтернативой XML и JSON? [закрыто]

Считается ли CSV хорошим вариантом против XML и JSON для языков программирования?

Я обычно использую XML и JSON (или иногда простой текстовый файл) в качестве хранилища плоских файлов. Однако недавно я наткнулся на реализацию CSV в PHP . Я обычно видел, что CSV используется для ввода в файлы Excel , но я никогда не использовал его в программировании. Будет ли это лучше, чем XML или JSON в любом случае?

Ответ, это зависит.

CSV отлично подходит для определенных случаев использования. Например, в качестве «потокового» формата для больших наборов данных потоковую передачу проще, чем XML / JSON, а файлы CSV занимают гораздо меньше места для хранения. Я использую его для потоковых наборов данных в диапазоне гигабайт, где другие форматы нецелесообразны.

Это также действительно распространено в определенных отраслях, когда речь идет об устаревших системах и рабочих процессах. Попробуйте импортировать JSON в MS Excel.

ODI недавно прокомментировал CSV, назвав 2014 год «Годом CSV».

Для "правильного" форматирования CSV, рассмотрите использование типа mime CSV в ваших ответах HTTP.

Конечно, нет.

CSV - это табличный формат, который очень хорошо отображается на наборы данных или другие табличные данные. Но не все данные являются табличными! В общем, мы хотим сериализовать графы объектов . Это может быть сложно в следующих случаях:

• циркулярные ссылки
• общие подграфы (например, два объекта, каждый из которых содержит один и тот же объект в качестве члена)
• объекты разных типов для сериализации в один и тот же документ

Кроме того, мы хотим иметь возможность надежно десериализовать объекты из нашего формата хранения.

XML

Это прежде всего расширяемый язык разметки . Он также может быть использован для хранения общих структур данных. Языковая поддержка идентификаторов означает, что можно создавать сложные графы, хотя лучше всего их использовать для деревьев. Документ может быть проверен на соответствие спецификации. Существуют различные проблемы с этим форматом, которые могут сделать его непрактичным, например, крайняя детализация.

JSON

Это прежде всего способ хранения простых объектных деревьев . Нет поддержки общих графиков. JSON не имеет понятия о типе, кроме примитивов 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, которые не согласны с разделителями, разделителями строк, кавычками, escape-символами и многими другими проблемами, которые делают его непригодным для общих (двоичных) данных. Все это затрудняет обработку данных в формате CSV.

Таким образом, в основном, простые вещи сложны или невозможны с CSV при использовании его в качестве общего формата сериализации.

Эта критика неприменима при использовании ее для хранения действительно табличных данных, таких как табели учета рабочего времени или серии измерений. Здесь CSV (часто в варианте значений, разделенных табуляцией) обычно более компактен и проще в использовании, чем другие форматы данных.

Я также должен сказать, что это зависит от того, чего вы пытаетесь достичь. Для многих проблем не имеет значения, что вы выберете, если проблема достаточно мала и ваш выбор хорошо согласуется с существующей системой.

Использование устаревшей системы и попытка использовать новый формат в чистом виде иногда могут быть проблемой, поскольку вы представили более сложную систему и имеете новую систему ввода для отладки. Я часто видел это, когда новые люди предпочитают что-то отличное от того, что существует, или когда появляется новый формат, и они хотят поэкспериментировать с этим. Это может быть или не быть хорошей идеей, это зависит от обстоятельств.

Несколько лет назад я работал над системой баз данных графов исследований, которая зависела от файлов CSV различных форматов. Импортер CSV-файлов построил бы для нас графики, и ему потребовалось много лет, чтобы отладить и оптимизировать код. Он был быстрым и гибким, и мы с радостью использовали бы его для запуска крупных исследовательских проектов. Когда XML появился на сцене, мы добавили импортер XML, но это не обязательно было улучшение с точки зрения скорости или выражения сложности, и, конечно, XML не был лучше в выражении структур графа, чем CSV. JSON намного лучше (и более лаконичен), чем XML, но во многих отношениях он похож, поэтому я ожидаю аналогичного результата при создании нового импортера в этой системе.

В какой-то момент у нас был заказчик, который вносил огромное количество данных в (как мы это назвали) формате «cobol», файлы с линиями переменной длины, содержащими маркеры, которые указывали, как интерпретировать байты, которые следуют в этой строке. Это произошло из-за того, что хранение было дорогим, поэтому требовалась компактность. Мы импортировали эти данные, преобразовав их в формат CSV на лету и загрузив в импортер CSV. Это было легко сделать и минимизировало количество отладки и обслуживания, и это хорошо. Если бы нам приходилось все время импортировать такие данные, мы могли бы встроить их в систему напрямую, чтобы повысить производительность и эффективность.

Таким образом, это зависит от того, что вы делаете, и от того, что делает базовая система. В моем примере импортер CSV был надежным и надежным. Я бы не решался сказать вам, что один формат был лучше или хуже, не понимая, что происходит в других слоях, которые я создаю. Я люблю JSON и предпочитаю его, но я знаю, что, учитывая определенные сложные структуры данных и достаточно большие наборы данных, файлы CSV также могут работать очень хорошо.

Нет.

CSV на самом деле не единственный формат. Существует множество стилей для экранирования, разделителей и других проблем форматирования, которые встречаются во многих CSV-файлах.

Если вы собираетесь использовать это как хранилище плоских файлов, использование JSON поможет вам намного лучше. JSON отображает объекты на объекты с гораздо меньшими хлопотами, чем для этого потребуется CSV.

Я настоятельно советую против этого. Я мог бы быть в порядке, чтобы вывести CSV в какой-то момент (если пользователь запрашивает его). Но это плохо подходит для хранения / импорта. В основном это связано с тем, что «CSV» очень плохо определен. «C» означает «запятая» или «символ» разделены? Как вы относитесь к текстовым строкам, которые содержат управляющие символы, такие как «? Каждая проклятая реализация CSV по-разному обрабатывает управляющие символы и т. Д., Что приводит к файлам, которые могут быть исключены, но не импортированы и т. Д.

Excel - хорошая демонстрация: в английской версии он использует «,» в качестве разделителя. В Германии он использует «;». Таким образом, немецкая версия задыхается от английских файлов CSV, и наоборот ...

Его главная сила - удобочитаемость, которую нельзя сбрасывать со счетов. Но я бы не стал полагаться на него как на формат хранения, он слишком хрупкий для этой цели. Если вам нужно экспортировать файлы для людей, вы можете использовать CSV, но даже тогда я бы попытался использовать библиотеку, которая записывает в файлы xlsx (они доступны бесплатно).

В общем нет. Зачем? JSON и XML существуют для того, чтобы избавиться от страшного CSV. Это структурированные подходы того, что было сделано неструктурированным с CSV в течение длительного времени. Да, в некоторых случаях использование CSV по-прежнему предпочтительнее, но в целом в 9 из 10 случаев лучше не использовать CSV.