Чому ми продовжуємо використовувати CSV? [зачинено]

Чому ми продовжуємо використовувати CSV?

Нещодавно я перейшов до роботи в галузі охорони здоров’я, і, незважаючи на чудову роботу в галузі стандартів передачі даних, вся передача даних відбувається в CSV , як для звітування перед зовнішніми організаціями, так і для міграції даних при впровадженні нових систем.

На жаль, використання CSV є причиною нескінченного повторення одних і тих же дурних помилок з однаковою витратою часу розробника. (поганий втечу, невміння обробляти нульові поля тощо)

Я знаю, що ми можемо зробити краще, і все, що між JSON та XML (залежно від примірника) було б добре. (Найчастіше це дані, що переходять від одного MS SQLserver 2005 до іншого!)

Я відчуваю себе так, ніби кожен раз, коли я бачу це, я буквально спостерігаю, як один розробник витрачає інший час.

То чому ми продовжуємо валити один одного? Коли ми зупинимось?

У вашому випадку, здається, що CSV не дуже підходить через відсутність жорстких специфікацій.

Для нетривіальних даних це не правильний вибір.

Чому / коли CSV - це вдалий вибір? Можливо, занадто багато випадків, щоб згадати, переваги простоти для плоских даних очевидні. Доки дані належним чином очищені / уникнути, проблем немає. Взагалі кажучи, всі ці випадки були б простими / тривіальними. Звичайно, стандартний роздільник, який з’являється у вмісті, часто є болем при роботі з CSV.

Але якщо ви робите щось більше, ніж залучати нетехнічного клієнта для надсилання даних із аркуша Excel або іншого подібного випадку, CSV, ймовірно, недостатній для будь-якого серйозного використання.

XML набагато краще підходить (так, навіть більше, ніж JSON), оскільки ви можете зробити детальну стандартизовану специфікацію схеми для цього. (Не кажучи вже про те, що специфікації / схеми користуються гнучкістю декількох стилів реалізації, XSD, DTD & Relax NG)

Для систем із замкнутим циклом, особливо коли пропускна здатність викликає занепокоєння, JSON може бути кращим, ніж XML, однак відсутність мови специфікацій схеми часто перешкоджає його застосуванню на рівні підприємств.

Дозвольте викинути кілька пунктів на користь CSV:

• CSV простий (r, ніж будь-яка альтернатива, запропонована в ОП) для реалізації та розбору
• CSV розуміється майже у кожному програмному забезпеченні планети (минулому та теперішньому)
• CSV створює досить рівну просту схему (є єдиний плоский список полів)
• CSV читає людину, ніж XML, JSON або (UGH!) HL7 (V2.x, pre-xml)

Зворотна сумісність. Якщо ваша зовнішня веб-служба orgs обробляє CSV, а всі існуючі інструменти обробляють CSV, жодна сторона не має жодної мотивації переходити до нової послуги. Чому ваш зовнішній орган почав підтримувати інший формат? Ніхто, з ким вони працюють, не може ним користуватися! Чому б ви почали виробляти інший формат? Жодна з організацій, з якими ви працюєте, не приймає це!

Реальна проблема , яку я бачу тут, чому ваші розробники коченню свій власний код CSV кожен раз? Якби вони використовували стабільну, надійну бібліотеку CSV, у них не було б проблем, які ви описуєте. Проблеми викликані розробниками, які замість використання бібліотеки прокатують власне рішення, і я, чесно кажучи, не бачу, як магічне переміщення до JSON або XML це виправляє. У вас все ще будуть люди, які намагаються їх повторно налаштувати замість бібліотеки.

CSV трохи швидший , меншого розміру , дуже простий в обробці (навіть в Excel), і багато існуючих додатків розуміють це, це широко використовуваний стандарт .

Це все ще перший вибір у багатьох ситуаціях.

Мені особисто все ще дуже подобається такий формат. Але я використовую і JSON, але для інших додатків, таких як веб-інтерфейс.

Перш за все, тому що, хоча споживання даних CSV може бути (трохи) нетривіальним, генерувати це надзвичайно просто.

Я також зазначу, що ані JSON, ані XML справді не простіші права (як для виробника, так і для споживача). Насправді, навряд чи варто озирнутися, щоб знати, що багато людей намагаються використовувати регулярні вирази для аналізу XML-даних, хоча абсолютно не виникає сумніву, що це не може і не спрацює.

Більшість проблем, які можуть (і можуть) виникнути з CSV, можуть (і зробити) також і з JSON, і з XML. XML, зокрема, додає ще багато власних потенційних проблем. Бібліотека для аналізу XML-даних, як правило, більша, повільніша і складніша, ніж аналогічна бібліотека для CSV-даних.

По-перше, я погоджуюсь, що з форматом є деякі дуже реальні проблеми:

• Це строго набрано.
  • Без розрізнення між текстовими та цифровими значеннями, Excel вгадає неправильно та викрутить ваші поштові індекси та номери кредитних карток.
  • Не існує стандартного способу представлення двійкових даних.
  • Не існує стандартного способу розмежування NULLі '', що є проблемою при імпорті CSV-файлів у бази даних SQL.
• Погана підтримка "особливих персонажів".
  • Відсутність числових посилань символів, таких як (XML &#xNNNN;або JSON \uNNNN), означає, що немає стандартного способу представлення контрольних символів або символів, що не належать до ASCII.
  • Багато реалізацій не реалізують належним чином розриви рядків у полі.
• Відсутність стандарту. Існує RFC 4180 , але його не дотримуються повсюдно.

Але з іншого боку:

• Альтернативи гірші. JSON і XML, розроблені навколо дерев, погано підходять для даних на основі таблиць, зокрема з точки зору ...
• КОМПАКТНІСТЬ! У XML ви повинні мати початковий тег та кінцевий тег для кожного стовпця в кожному рядку. У CSV ви пишете заголовки стовпців лише один раз.
• CSV дуже легко генерувати.
• Непрограмісти можуть відкривати файли CSV в Excel.

Оскільки багато аналітиків використовують Excel (для зведених таблиць тощо), і вивести CSV набагато простіше, ніж виводити власний формат Excel.

Виноска: враховуючи, скільки проблем у Excel було пов’язано з обробкою файлів CSV, як-от видалення перших нулів та втрата точності, це, мабуть, помилкове відчуття простішого.

Якщо з CSV щось не так, це те, що CSV видається настільки простим, що багато розробників намагаються винайти власні парсери / автори, а пізніше звинувачують CSV у неправильному виконанні операцій із втечею. З хорошим аналізатором CSV (багато хорошого там) взагалі не буде проблем.

Один згаданий CSV не підходить для нетривіальних даних, але я не згоден. XML дозволяє нетривіальні дані, оскільки різні набори даних можуть бути поміщені в різні "контейнерні" теги. За допомогою CSV ви завжди можете розміщувати різні дані у різних файлах, щоб досягти однакового ефекту.

Крім того, на мою думку, використання XML для передачі даних принципово суперечить меті XML - передача даних зазвичай передбачає стабільний контракт між постачальниками та споживачами, тоді як XML має на меті нести розширювану інформацію, що підлягає інтерпретації під час її споживання.

Я думаю, що CSV просто хороший, коли у вас є лише прості текстові дані, у яких лише коми, або крапка з комою / кінцею в кінці.

Дерево архітектурні дані або складені дані навряд чи можна використовувати з CSV.

CSV - це просто звичайний 2D-масив тексту, як у excel, нічого особливого ...

Тут дійсно все стосується мейнфреймів та видатних результатів.

Мейнфрейми, тому що ті старі системи з'ясували, як спілкуватися за допомогою CSV. Тож великі програми, які скидають дані, можуть читати та записувати їх і тепер не мають жодних причин змінювати.

Excel, оскільки він може відкривати CSV безпосередньо. Фактично, він приймає розширення .csv при його встановленні. Користувачі просто натискають на трохи кумедний на вигляд Excel значок, і він відкривається, і створює приємну сітку, з якою вони можуть скластись.

Тепер сучасні версії excel цілком здатні читати, скажімо, XML безпосередньо. Але для цього користувач повинен трохи більше зрозуміти, що "двічі клацніть на цій картинці". І подвійне клацання праворуч може бути занадто багато, щоб запитати в деяких галузях. . .

Я бачив багато технічних відповідей, але підозрюю, що люди використовують CSV - це та сама причина, чому люди використовують багато інших методик / технологій: тому що це той, з ким вони найбільш знайомі

чому я його використовую?

1. замовник цього хоче
2. це швидше, ніж xml по мережі (менша завантаженість мережі)
3. нічого більш складного для отримання даних не потрібно
4. поперечна платформа
5. людський читабельний
6. прості у виконанні читачі та письменники для цього

тощо.