Dlaczego nadal używamy CSV? [Zamknięte]

Dlaczego nadal używamy CSV?

Niedawno przeszedłem do pracy w dziedzinie zdrowia i pomimo wspaniałej pracy w standardach przesyłania danych, wszystkie przesyłane dane są w CSV , zarówno w celu raportowania do organizacji zewnętrznych, jak i migracji danych podczas wdrażania nowych systemów.

Niestety użycie CSV powoduje niekończące się powtarzanie tych samych głupich błędów przy tym samym marnowaniu czasu programisty. (złe ucieczka, brak obsługi pustych pól itp.)

Wiem, że możemy zrobić lepiej i wszystko między JSON a XML (w zależności od instancji) byłoby w porządku. (Przez większość czasu są to dane przesyłane z jednego MS SQLserver 2005 do drugiego!)

Mam wrażenie, że za każdym razem, gdy to widzę, dosłownie patrzę, jak jeden programista marnuje czas innym.

Dlaczego więc ciągle się nawracamy? Kiedy się zatrzymamy?

W twoim przypadku wydaje się, że CSV nie jest dobrze dopasowany ze względu na brak twardej specyfikacji.

W przypadku nietrywialnych danych nie jest to właściwy wybór.

Dlaczego / Kiedy CSV jest dobrym wyborem? Prawdopodobnie zbyt wiele przypadków, aby wspomnieć, korzyści wynikające z prostoty płaskich danych są oczywiste. Tak długo, jak dane są odpowiednio odkażane / usuwane, nie ma żadnych problemów. Ogólnie rzecz biorąc, wszystkie te przypadki byłyby proste / trywialne. Oczywiście standardowy ogranicznik pojawiający się w treści jest często uciążliwy w kontaktach z CSV.

Ale jeśli robisz coś bardziej zaangażowanego niż pozyskiwanie nietechnicznego klienta do wysyłania danych z arkusza Excela lub innego podobnego przypadku użycia, CSV prawdopodobnie nie wystarcza do poważnego wykorzystania.

XML jest znacznie lepiej dopasowany (tak, nawet bardziej niż JSON), ponieważ możesz dla niego wykonać szczegółową znormalizowaną specyfikację schematu. (Nie wspominając o tym, że specyfikacje / schematy cieszą się elastycznością wielu stylów implementacji, XSD, DTD i Relax NG)

W przypadku systemów z zamkniętą pętlą, szczególnie tam, gdzie problemem jest przepustowość, JSON może lepiej pasować niż XML, ale brak języków specyfikacji schematu często wyklucza to z aplikacji na poziomie korporacyjnym.

Pozwolę sobie wyrzucić kilka punktów na korzyść CSV:

• CSV jest prosty (r niż jakakolwiek alternatywa sugerowana w OP) do wdrożenia i parsowania
• CSV jest rozumiany przez prawie każde oprogramowanie na planecie (przeszłość i teraźniejszość)
• CSV wymusza dość płaski, prosty schemat (istnieje jedna płaska lista pól)
• CSV jest bardziej czytelny dla ludzi niż XML, JSON lub (UGH!) HL7 (V2.x, pre-xml)

Kompatybilność wsteczna. Jeśli Twoja zewnętrzna usługa sieci web organizacji obsługuje CSV, a wszystkie istniejące narzędzia obsługują CSV, żadna ze stron nie ma motywacji, aby przejść do nowej usługi. Dlaczego Twój organ zewnętrzny miałby obsługiwać inny format? Nikt, z kim pracują, nie może z niego korzystać! Dlaczego zaczniesz produkować inny format? Żadna z organizacji, z którymi współpracujesz, nie akceptuje tego!

Prawdziwy problem widzę tu jest, dlaczego programiści toczenia własnego kodu CSV za każdym razem? Gdyby użyli stabilnej, solidnej biblioteki CSV, nie mieliby problemów, które opisujesz. Problemy są spowodowane przez deweloperów wprowadzających własne rozwiązania zamiast korzystania z biblioteki, i szczerze mówiąc, nie widzę, jak przejście do JSON lub XML magicznie to naprawia. Nadal będziesz mieć ludzi próbujących je regexować zamiast korzystać z biblioteki.

CSV jest nieco szybszy , mniejszy , bardzo łatwy w obsłudze (nawet w programie Excel) i wiele istniejących aplikacji to rozumie, jest to powszechnie stosowany standard .

Jest to nadal pierwszy wybór w wielu sytuacjach.

Osobiście nadal bardzo lubię ten format. Ale ja też używam JSON, ale do innych aplikacji, takich jak interfejs WWW.

Przede wszystkim dlatego, że mimo spożywania dane CSV może być (nieznacznie) nietrywialne, generując go jest bardzo proste.

Chciałbym również zauważyć, że ani JSON, ani XML nie jest tak naprawdę łatwiejszy do uzyskania (zarówno dla producenta, jak i konsumenta). W rzeczywistości prawie wcale nie trzeba się rozglądać, aby wiedzieć, że wiele osób próbuje używać wyrażeń regularnych do analizowania danych XML, nawet jeśli absolutnie nie ma wątpliwości, że to nie może i nie będzie działać.

Większość problemów, które mogą (i robią) z CSV, mogą (i robią) również z JSON i XML. W szczególności XML dodaje wiele innych potencjalnych problemów. Biblioteka do analizy danych XML jest na ogół większa, wolniejsza i trudniejsza w użyciu niż podobna biblioteka dla danych CSV.

Po pierwsze, zgadzam się, że istnieją bardzo realne problemy z formatem:

• Jest ściśle napisany.
  • Bez rozróżnienia między tekstem a wartościami liczbowymi Excel zgadnie źle i zepsuje twoje kody pocztowe i numery kart kredytowych.
  • Nie ma standardowego sposobu reprezentowania danych binarnych.
  • Nie ma standardowego sposobu rozróżnienia między NULLi '', co stanowi problem podczas importowania plików CSV do baz danych SQL.
• Słaba obsługa „znaków specjalnych”.
  • Brak odniesień do znaków numerycznych, takich jak (XML &#xNNNN;lub JSON \uNNNN) oznacza, że ​​nie ma standardowego sposobu reprezentowania znaków sterujących lub znaków spoza ASCII.
  • Wiele implementacji nie implementuje poprawnie podziałów linii w polu.
• Brak standardu. Istnieje RFC 4180 , ale nie jest powszechnie stosowany.

Ale z drugiej strony:

• Alternatywy są gorsze. JSON i XML, ponieważ są zaprojektowane wokół drzew, nie nadają się do danych tabelowych, szczególnie pod względem ...
• ŚCISŁOŚĆ! W XML musisz mieć znacznik początkowy i końcowy dla każdej kolumny w każdym rzędzie. W CSV nagłówki kolumn zapisujesz tylko raz.
• Plik CSV jest bardzo łatwy do wygenerowania.
• Osoby niebędące programistami mogą otwierać pliki CSV w programie Excel.

Ponieważ wielu analityków korzysta z programu Excel (w przypadku tabel przestawnych itp.), A wyjście CSV jest znacznie łatwiejsze niż wyjściowy format Excel.

Przypis: biorąc pod uwagę liczbę problemów, jakie widziałem podczas obsługi plików CSV w programie Excel, takich jak usuwanie zer wiodących i utrata precyzji, jest to prawdopodobnie fałszywe poczucie, że jest łatwiejsze.

Jeśli jest coś nie tak z CSV, to znaczy, że CSV wydaje się tak prosty, że wielu programistów próbuje wymyślić własne parsery / programy piszące, a później obwinia CSV za niepoprawne obchodzenie się z ucieczką. Przy dobrym parserze CSV (wielu tam dobrych) nie będzie żadnego problemu.

Ktoś wspomniał, że CSV nie nadaje się do nietrywialnych danych, ale nie zgadzam się. XML pozwala na nietrywialne dane, ponieważ różne zestawy danych można umieszczać w różnych znacznikach „kontener”. Dzięki CSV możesz zawsze umieszczać różne dane w różnych plikach, aby osiągnąć ten sam efekt.

Co więcej, moim zdaniem, używanie XML do przesyłania danych zasadniczo stoi w sprzeczności z celem XML - transfer danych zwykle oznacza stabilną umowę między dostawcami a konsumentami, podczas gdy XML ma na celu przenoszenie rozszerzalnych informacji podlegających interpretacji, gdy są wykorzystywane.

Sądzę, że CSV są po prostu dobre, gdy masz tylko proste dane tekstowe, z przecinkami i średnikiem / końcem na końcu.

Dane w architekturze drzewa lub dane złożone nie mogą być używane w CSV.

CSV to po prostu zwykła tablica 2D jak w programie Excel, nic więcej ...

Tutaj naprawdę chodzi o komputery mainframe.

Komputery mainframe, ponieważ te stare systemy wymyśliły sposób komunikacji przy użyciu CSV. Tak więc duże aplikacje, które zrzucają dane, mogą je odczytywać i zapisywać i nie mają powodu, aby je teraz zmieniać.

Excel, ponieważ może bezpośrednio otwierać pliki CSV. W rzeczywistości przejmuje rozszerzenie .csv podczas instalacji. Użytkownicy po prostu klikają nieco śmiesznie wyglądającą ikonę programu Excel, która otwiera się i tworzy fajną siatkę, z którą mogą się pokłócić.

Teraz nowoczesne wersje programu Excel są w stanie odczytywać, powiedzmy, XML bezpośrednio. Ale aby to zrobić, użytkownik musi zrozumieć coś więcej niż „podwójne kliknięcie na to zdjęcie”. Dwukrotne kliknięcie prawego zdjęcia może być zbyt wielkim pytaniem w niektórych branżach. . .

Widziałem wiele technicznych odpowiedzi, ale podejrzewam, że ludzie używają CSV to ten sam powód, dla którego ludzie używają wielu innych technik / technologii: ponieważ jest to jedna z nich, którą najbardziej znają

dlaczego z niego korzystam

1. klient tego chce
2. jest szybszy niż xml przez sieć (mniejsze obciążenie sieci)
3. nic bardziej złożonego nie jest potrzebne do przekazywania danych
4. między platformami
5. czytelny dla człowieka
6. łatwe do wdrożenia czytelników i pisarzy

itd itd.