Wpis użytkownika Ragnarokk w Hydepark

@Eruanno No to najwyraźniej nie wszyscy

Przecież oba formaty możesz dodatkowo tak samo skompresować, co to za argument.

@GazelkaFarelka Przepraszam najmocniej, ale dalej nie rozumiesz. Toon próbuje oszczędzać wielkość pliku, poprzez skomplikowanie składni (wymaga parsowania semantyki! prostej bo prostej, ale wciąż! Wprowadza prosty system typów!), podczas gdy można skompresować JSONa i osiągnąć nawet lepsze wyniki niż Toon. Po kompresji, oba powinny mieć marginalnie podobne wielkości. Więc pytanie: po co Ci to?

> Różnica jest taka, że jak masz format możliwy do odczytywania porcjami, na przykład linia po linii, to na np. trzy miliony rekordów błąd parsowania w jednej linii nie rozwali ci całego odczytu pliku.

To jest akurat bzdura: JSONa da się recoverować, brak `}` albo `"` jest do naprawienia przy tak samo prostej strukturze jaką obsługuje Toon więc jaki problem tak naprawdę rozwiązuje?

@Ragnarokk Tzn zgadzam się z tym, że ten toon jest to dosłownie CSV - niczym się w ogóle od niego nie różni. Ale rozumiem zamysł za tym stojący. Dlatego zaproponowałam moje rozwiązanie, które zmniejsza rozmiar pliku w podobny sposób, a jednocześnie jest nieco lepsze niż toon i CSV, bo eliminuje jego pewne wady.

Miałbyś header w tym stylu - gdzie deklarujesz typy, strukturę wiersza, pozwalającą też na zagnieżdżone struktury:

{"firstname": string, "lastname": string, "birthday": date, "father": {"firstname": string, "lastname": string}, "mother": {"firstname": string, "lastname": string}, children: {"firstname": string, "lastname": string}}

Oraz dane (każdy w osobnej linii)

{"Jan","Kowalski","1967-05-12",{"Wacław","Kowalski"},{"Janina","Kowalska"},[{"Zofia","Kowalska"}, {"Antoni","Kowalski"}]}

Dostajesz ten sam zysk to w toon i csv (oszczędzony rozmiar pliku na kluczach - no, nie dokładnie ten sam, u mnie jest odrobinę więcej bo są klamry i delimitery), a jednocześnie możliwość zapisywania bardziej złożonej struktury danych niż flat oddzielony przecinkami, a w przypadku danych w relacji jeden do wielu, konieczności zrzucania tego do dwóch osobnych plików (na moim przykładzie jakby to był csv, to musiałbyś zrobić dwa pliki - people.csv i children.csv i nie miałbyś dostępu do wiedzy o childrenach przetwarzając people.csv)

@baklazan Przecież oba formaty możesz dodatkowo tak samo skompresować, co to za argument.

Różnica jest taka, że jak masz format możliwy do odczytywania porcjami, na przykład linia po linii, to na np. trzy miliony rekordów błąd parsowania w jednej linii nie rozwali ci całego odczytu pliku. Przetworzysz sobie poprawnie 2 999 999 wierszy danych, a ten jeden wadliwy rekord zaraportujesz jako błąd.

@GazelkaFarelka OMG, słownik... "Żołnierz" - miało być zipujesz.

Chodzi mi o to że celem tego formatu jest ograniczenie powtórzeń kluczy w celu zmniejszenia pliku. Tyle że tym się zajmują algorytmy kompresji, z automatu, bez ludzkiej ingerencji.

Dlaczego zrzucać sprawdzanie błędów semantycznych na parser? Siłą JSONa jest to że jest taki jak go zinterpretujesz, parser ma minimalne wymagania co do pliku, tak, możesz zgubić cudzysłów, ale równie dobrze w Twoim możesz zgubić przecinek, albo może Ci wpaść jeden ekstra, masz ten sam problem.

@GazelkaFarelka Obrazek porównuje z JSON, ale ja porównuje z CSV.

@megawonsz9 Co? Json jest po to, żeby zakodować wielowymiarowe dane o dowolnej strukturze. Owszem, lepiej się to czyta i jest idealne do wymiany relatywnie niewielkich porcji danych. Jeżeli jednak masz dane, które są monstrualne, gdzie struktura każdego rekordu jest identyczna, to można pominąć deklarowanie jej w de facto każdym elemencie. Z tym, że wadą CSV jest płaski wymiar i brak możliwości określenia typów danych.

Ogólnie wymiana danych polegająca na przetwarzaniu plików to kupa :stuck_out_tongue_closed_eyes:

@dzek kompresję masz tak czy siak, tu i tu, a realnie ile oszczędzisz zależy od wielkości danych w wierszu, to czysty tekst więc bardzo łatwo policzyć dla konkretnego zestawu danych

@GazelkaFarelka Przeca jsona nie używa się po to żeby zaoszczędzić miejsce tylko po to żeby dobrze się go czytało oczami. Ten TOON nawet w przykładzie to padaka bo trzeba co chwila zerkać do headera, przy większej ilości tekstu równie dobrze można trzymać te dane w jakimś binarnym formacie który pewnie i tak byłby bardziej czytelny niż to xd

@GazelkaFarelka pytanie ile realnie na realnych danych to oszczędza, uwzględniając kompresję, jakiegoś bieda gzipa, nie mówiąc o brotli

Do tego jak wygląda zagnieżdżanie? Gdzie typy? Czy to działa tylko dla płaskiej "struktury" w której wszystko jest stringiem?

@baklazan Nie rozumiem zarzutów, w każdym formacie można zrobić błędy. W mojej propozycji jest o tyle lepiej, że jeżeli odczytany wiersz nie pasuje do podanej w headerze struktury to go odrzucasz w przetwarzaniu - nie wywala ci po zaciagnięciu i załadowaniu do pamięci całego 3 GB pliku "json parse error", bo gdzieś tam ktoś nie escapował delimitera.

@GazelkaFarelka bullshit. Żołnierz jak potrzebujesz miejsca i tyle. To gówno wymaga deklaracji, więc wymaga w cholerę zmian w których łatwo o błędy, przedwczesna optymalizacja to źródło wszelkiego zla

@Czokowoko Tu jest porównanie z json więc wymyśliłam jak dołożyć do tego po prawej zalety jsona a jednocześnie utrzymać większą kompaktowość danych, którą daje format po prawej. Oczywiście zakładaǰac, że przekazujemy dużą ilość danych (wtedy te zyski na kB mają znaczenie), a wszystkie elementy mają tą samą strukturę. Można każdy element dawać nawet w nowej linii, dzieki czemu można by odczytywać i przetwarzać linia po linii, zamiast wczytywania najpierw całości do pamięci, co ma znaczenie przy bardzo dużych plikach.

@GazelkaFarelka Wszystko zależy co chcesz wysyłać, w jaki sposób i ile. No i czy ktoś nie będzie musiał tego czytać potem przy debugowaniu XD

@dziad_saksonski no to ok, ale te stringi to troche imo przesada

@bartek555 nie no co ty, kazdy szanujący się zdalny pracownik siedzi w szlafroku z piwerkiem

@dziad_saksonski lol, nie mozecie w normalnej bieliznie pracowac?

@dziad_saksonski Oj tam, oj tam 😛

@dziad_saksonski i obsłudze typu zmiennej też

@ZohanTSW zróbmy dla beki format który zatem połączy wady wszystkich standardów, ale z jakiegoś dziwnego powodu się przyjmie, bo ci którzy z niego korzystali, dla beki będą go polecać innym.

@serel jest tyle standardów, że głowa boli... Zróbmy zatem kolejny, ale taki, który połączy zalety wszystkich standardów, i będzie standardem ostatecznym!

@vrkr Ma swoje plusy - jest to format Excelowy, a klienci nietechniczni lubią Excele. Można lubić albo nie lubić, dane będziesz dostawal w tabelkach :grinning: