Czy CSV jest dobrą alternatywą dla XML i JSON? [Zamknięte]

Czy CSV jest uważany za dobrą opcję przeciwko XML i JSON dla języków programowania?

Ogólnie używam XML i JSON (lub czasem zwykłego pliku tekstowego) jako płaskiego miejsca do przechowywania plików. Ostatnio jednak natknąłem się na implementację CSV w PHP . Generalnie widziałem CSV używany do wprowadzania danych w plikach Excel , ale nigdy nie korzystałem z niego przy programowaniu. Czy w jakikolwiek sposób byłby lepszy niż XML lub JSON?

Odpowiedź brzmi: to zależy.

CSV doskonale nadaje się do niektórych przypadków użycia. Na przykład jako format „streaming” dla dużych zestawów danych, łatwiej jest przesyłać strumieniowo niż XML / JSON, a pliki CSV zajmują znacznie mniej miejsca do przechowywania. Używam go do przesyłania strumieniowego zbiorów danych w zakresie gigabajtów, gdzie inne formaty są niepraktyczne.

Jest to również bardzo powszechne w niektórych branżach, gdy mamy do czynienia ze starszymi systemami i przepływami pracy. Spróbuj zaimportować JSON do MS Excel.

ODI niedawno skomentował CSV, nazywając 2014 rok „Rokiem CSV”

Aby uzyskać „prawidłowe” formatowanie CSV, rozważ użycie typu mime CSV w swoich odpowiedziach HTTP.

Na pewno nie.

CSV to format tabeli, który bardzo dobrze odwzorowuje na zestawy danych lub inne dane tabelaryczne. Ale nie wszystkie dane są tabelaryczne! Ogólnie rzecz biorąc, chcemy serializować wykresy obiektów . Może to być trudne w następujących przypadkach:

• okólniki
• współdzielone podgrafy (np. dwa obiekty, które zawierają ten sam obiekt jako element członkowski)
• obiekty różnych typów, które mają być serializowane do tego samego dokumentu

Chcemy ponadto móc niezawodnie usuwać z serializacji obiekty z naszego formatu pamięci.

XML

Jest przede wszystkim rozszerzalnym językiem znaczników . Można go ustawić tak, by przechowywał również ogólne struktury danych. Obsługa języka dla identyfikatorów oznacza, że ​​można tworzyć złożone wykresy, chociaż najlepiej nadają się do drzew. Dokument można przetestować pod kątem poprawności względem specyfikacji. Istnieją różne problemy z tym formatem, które mogą sprawić, że będzie on niepraktyczny, na przykład ekstremalna gadatliwość.

JSON

Jest przede wszystkim sposobem przechowywania prostych drzew obiektów . Nie ma obsługi ogólnych wykresów. JSON ma koncepcji typu poza prymitywów ciąg , liczba całkowita , pływak , Boolean , wartość null i typów kolekcji tablicy i obiektu .

YAML

Najłatwiej rozumiane jako rozszerzenie JSON. Ma pojęcie aliasów, które umożliwiają tworzenie grafów obiektowych o dowolnej złożoności. Ma koncepcję metadanych, takich jak tagi , których można używać do poprawnego pisania.

CSV

Nie ma nic oprócz jednego stołu. Jeśli chcemy przechowywać wykresy obiektowe, musielibyśmy użyć schematu podobnego do schematu

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

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

Istnieje wiele dialektów CSV, które nie zgadzają się co do ograniczników, terminatorów linii, cytowania, znaków zmiany znaczenia i wielu innych kwestii, które sprawiają, że nie nadaje się do ogólnych (binarnych) danych. Wszystko to utrudnia przetwarzanie danych CSV.

Zasadniczo, łatwe korzystanie z CSV jest trudne lub niemożliwe, gdy jest używany jako ogólny format serializacji.

Ta krytyka nie ma zastosowania, gdy używa się jej do przechowywania prawdziwie tabelarycznych danych, takich jak arkusze czasu lub serie pomiarów. Tutaj CSV (często w wariancie wartości rozdzielanych tabulatorami) jest zwykle bardziej zwarty i łatwiejszy w użyciu niż inne formaty danych.

Muszę też powiedzieć, że zależy to od tego, co próbujesz osiągnąć. W przypadku wielu problemów nie ma znaczenia, co wybierzesz, jeśli problem jest wystarczająco mały, a twój wybór dobrze pasuje do istniejącego systemu.

Przyjęcie starszego systemu i próba wyskakiwania w nowym formacie może czasem stanowić problem, ponieważ wprowadzono większą złożoność i nowy system wejściowy do debugowania. Widziałem to bardzo często, gdy nowi ludzie wolą coś innego niż to, co istnieje lub kiedy pojawia się nowy format i chcą z nim eksperymentować. To może, ale nie musi być dobrym pomysłem, zależy to od okoliczności.

Wiele lat temu pracowałem nad systemem baz danych wykresów badawczych, który opierał się na plikach CSV o różnych formatach. Importer plików CSV budował dla nas wykresy i miał wiele lat pracy nad debugowaniem i optymalizacją kodu. Była zarówno szybka, jak i elastyczna i chętnie wykorzystalibyśmy ją do uruchamiania dużych projektów badawczych. Kiedy na scenie pojawił się XML, dodaliśmy importera XML, ale niekoniecznie była to poprawa szybkości lub wyrażania złożoności, a na pewno XML nie był lepszy w wyrażaniu struktur grafów niż CSV. JSON jest o wiele ładniejszy (i szybszy) niż XML, ale pod wieloma względami jest podobny, więc oczekiwałbym podobnego rezultatu podczas tworzenia nowego importera w tym systemie.

W pewnym momencie mieliśmy klienta, który przyniósł ogromną ilość danych w formacie (jak to nazywamy) „cobol”, pliki z wierszami o zmiennej długości zawierające znaczniki wskazujące, jak interpretować bajty następujące po tej linii. Pochodzi z czasów, gdy przechowywanie było drogie, dlatego wymagana była kompaktowość. Zaimportowaliśmy te dane, konwertując je w locie do formatu CSV i przekazując je do importera CSV. Było to łatwe do zrobienia i zminimalizowało ilość debugowania i konserwacji, które są dobre. Gdybyśmy musieli cały czas importować tego rodzaju dane, moglibyśmy wbudować je bezpośrednio w system, aby uzyskać wzrost wydajności i wydajności.

To zależy od tego, co robisz i od tego, co robi system bazowy. W moim przykładzie importer CSV był solidnie zaprojektowany i niezawodny. Z wahaniem powiem wam, że jeden format był lepszy lub gorszy, nie rozumiejąc, co się dzieje w innych warstwach, które buduję. Uwielbiam JSON i wolę go, ale wiem, że przy pewnych złożonych strukturach danych i wystarczająco dużych zestawach danych, pliki CSV również mogą sprawić, że będą działały bardzo dobrze.

Nie.

CSV nie jest tak naprawdę jednym formatem. Istnieje wiele różnych stylów ucieczki, separatorów i innych problemów z formatowaniem, które ma wiele plików CSV na wolności.

Jeśli zamierzasz używać tego jako płaskiego magazynu plików, korzystanie z JSON będzie ci znacznie lepiej służyć. JSON mapuje do i z obiektów z dużo mniejszym kłopotem niż będziesz miał do tego kłopotliwy CSV.

Zdecydowanie odradzałbym to. W pewnym momencie mogę być w stanie wysyłać CSV (jeśli użytkownik tego zażąda). Ale to źle pasuje do celów przechowywania / importu. Wynika to głównie z faktu, że „CSV” jest bardzo źle zdefiniowany. Czy „C” oznacza „przecinek” lub „znak” oddzielone? Jak traktujesz ciągi tekstowe zawierające znaki specjalne, takie jak „? Każda przeklęta implementacja CSV traktuje znaki specjalne itp. Inaczej, co prowadzi do plików, które można ex- ale nie importować itp.

Excel jest dobrą demonstracją: w wersji angielskiej używa „,” jako separatora. W Niemczech używa „;”. Więc niemiecka wersja dusi się na angielskich plikach CSV i odwrotnie ...

Jego główną siłą jest czytelność dla ludzi, której nie należy lekceważyć. Ale nie polegałbym na nim jako formacie przechowywania, jest zbyt kruchy do tego celu. Jeśli musisz wyeksportować pliki dla ludzi, możesz użyć CSV, ale nawet wtedy spróbowałbym użyć biblioteki, która zapisuje pliki xlsx (są one swobodnie dostępne).

Ogólnie NIE. Czemu? JSON i XML są po to, aby pozbyć się przerażającego CSV. Są to ustrukturyzowane podejścia do tego, co zostało zrobione bez struktury z CSV przez długi czas. Tak, istnieją przypadki użycia, w których CSV jest nadal preferowany, ale ogólnie w 9 na 10 przypadków lepiej nie używać CSV.