Mała aktualizacja;
Kilka dni temu poprawiłem plik kolorowania składni dla edytora Notepad++ - teraz umożliwia prawidłowe zwijanie wieloliniowych komentarzy (wcześniej był z tym problem, czego nie zauważyłem); Nowa wersja tego pliku dostępna jest tutaj.
W czym forma binarna jest lepsza od sqlite? Czy język język zapytań jest lepszy od sql, czy api dla . net jest wygodniejsze w użyciu niż EntityFramework? Czy twój format jest szybszy od jednoplikowej bazy sqlite?
Zwykle ustawienia mojego programu serializuję do pliku xml (jedna linia kodu), a gdy trzeba, deserializuję i mam odtworzony cały obiekt klasy.
W czym wygodniejszy jest twój format?
Szalony Krawiec napisał(a):
W czym forma binarna jest lepsza od sqlite?
Dowolny tekstowy plik konfiguracyjny (bez względu na to czy mowa o INI, XML, YAML itd.) bez problemu można przedstawić w formie binarnej. Podczas serializacji, zamiast generować linijki ze znacznikami, identyfikatorami, ciągami danych i innych fraz, zapisuje się po prostu nazwę elementu, dodatkowe dane, liczbę elementów potomnych i te elementy, w ten sam sposób. Dzięki temu te same dane opisuje krótsza zawartość pliku, o z góry znanej budowie, łatwiejsza do przetwarzania.
Czy w ten sposób zserializowany np. XML będzie lepszy od SQLite? No nie bardzo – to w dalszym ciągu ten sam tekstowy plik konfiguracyjny, tyle że łatwiejszy do zrozumienia i przetworzenia dla komputera, ale trudniejszy do analizy dla człowieka.
Binarna forma to nic innego jak cache – szybsza serializacja i deserializacja, ta sama zawartość (wciąż tekstowa!).
Czy język język zapytań jest lepszy od sql, czy api dla . net jest wygodniejsze w użyciu niż EntityFramework?
Nie używam tych technologii, nie znam ich, więc nie powinienem się w tym temacie wypowiadać.
Czy twój format jest szybszy od jednoplikowej bazy sqlite?
Nie, i żaden inny format tekstowych konfiguracji nie jest i nie będzie szybszy od silników bazodanowych.
To raczej oczywiste – tekstowe pliki konfiguracyjne służą przede wszystkim programistom i użytkownikom, nie komputerowi. Dlatego są w całości tekstowe, da się je wygodnie tworzyć i czytać. Natomiast systemy bazodanowe stworzone są do bardzo szybkich operacji na dużej ilości danych, bez wymogu utrzymywania czytelnej dla człowieka struktury.
Zwykle ustawienia mojego programu serializuję do pliku xml (jedna linia kodu), a gdy trzeba, deserializuję i mam odtworzony cały obiekt klasy.
No to też dam radę zrobić jedną linijką kodu.
W czym wygodniejszy jest twój format?
W obsłudze z poziomu Free Pascala. Jest bardzo prosty w obsłudze (na poziomie klas TRegistry czy TIniFile), ale posiada od nich większą funkcjonalność – wsparcie większej liczby typów danych, wbudowana konwersja danych na różne formy, kupka metod do dodatkowych czynności itd. API nie jest też tak kobylaste i zagmatwane jak to do XML.
Ogólnie jestem z niego zadowolony, bo stworzyłem go (format i natywną libkę do jego obsługi) w taki sposób, aby spełniał moje oczekiwania. No i spełnia, choć jeszcze wiele pracy przede mną. ;)
Hmm chodziło raczej chyba o to, że twój plik w formie binarnej też jest zrozumiały tylko dla komputera, a sqlite jest przy tym szybszy i wygodniejszy, bo możesz użyć orm-a albo sql-a do odczytu/modyfikacji.
Format xml albo json też jest wygodniejszy, xml +xsd to wręcz kompletny opis całej struktury. Czy nie wynajdujesz aby koła na nowo?
Biały Lew1 napisał(a):
Hmm chodziło raczej chyba o to, że twój plik w formie binarnej też jest zrozumiały tylko dla komputera, a sqlite jest przy tym szybszy i wygodniejszy, bo możesz użyć orm-a albo sql-a do odczytu/modyfikacji.
Oczywiście – SQLite na pewno jest szybszy, nawet sprawdzać nie trzeba. Tyle że zwrócić należy uwagę na sam fakt porównania tekstowego pliku do systemu bazodanowego – pierwsze nie dorasta drugiemu do pięt, bez względu na to co oferuje.
W ogóle nie należy tych technologii zestawiać ze sobą, bo mają zupełnie różne przeznaczenie.
Format xml albo json też jest wygodniejszy, xml +xsd to wręcz kompletny opis całej struktury. Czy nie wynajdujesz aby koła na nowo?
W pewnym sensie tak, tyle że za późno o cztery lata na takie pytania. :]
No ale masz format binarny w tej twojej bibliotece. Skoro sqlite to też format binarny, a do tego szybszy niż format binarny twojej biblioteki, to w zasadzie jaki tu sens...
Ale przeznaczenie jest zupełnie inne, tak samo jak zakres funkcjonalności. Jeśli nie widzisz różnicy pomiędzy tsinfo a sqlite, to również nie będziesz jej widział pomiędzy np. xml a mysql.
Przeznaczenie nie jest inne, lecz dokładnie takie samo. Sqlite to właśnie jednoplikowa baza do trzymania ustawień w formie binarnej (zamiast tekstowego xml), a dlatego binarnej żeby było szybciej. Czyli mniej więcej ten sam cel, co forma binarna twojej biblioteki. Sqlite jest np natywnie wykorzystywany przez Androida do tego celu. Nie myl sqlite z bazami takimi jak mysql
Jeśli dobrze rozumiem:
... oba (obiektywnie) gorsze, niż te ogólnie przyjęte
Dla ciebie nie ma sensu, ale widzisz sens w deprecjonowaniu czyjeś pracy. Zadaj sobie trud przeczytania wątku w którym piszesz i odpowiedz na pytanie: Jaki jest sens zadawania takiego pytania?
Nie chodzi mi o deprecjonowanie czyjejś pracy, tylko chcę zrozumieć sens, może akurat tsinfo jednak w czymś jest lepsze
Wydaje się, że kolega po prostu nie wiedział, że są już gotowe formaty zapisu takich danych tekstowo (xml, xsd) i binarnie (sqlite) i świat z nich korzysta, albo w Lazarusie nie było dobrych komponentów do ich obsługi, więc postanowił napisać swój format. Oczywiście to ogrom pracy, ale nierealne jest prześcignąć istniejące analogiczne rozwiązania, to chyba nigdy nie było celem
Biały Lew1 napisał(a):
Przeznaczenie nie jest inne, lecz dokładnie takie samo.
Nie jest takie samo, a jedyne co łączy pliki konfiguracyjne i systemy bazodanowe to sam fakt przechowywania danych. Najpierw zapoznaj się z terminologią – czyli z tym czym jest plik konfiguracyjny oraz baza danych – a dopiero później będziemy mogli podyskutować. Choć jeśli zapoznasz się z tymi pojęciami, to nie będzie o czym dyskutować.
Jeśli dobrze rozumiem:
- tsinfo tekstowy -> xml
- tsinfo binarny -> sqlite
No nie, tłumaczę Ci, że plik tekstowy a binarny odróżnia wyłącznie struktura danych wewnątrz pliku. Zobacz, tak wygląda przykładowe drzewko w formie tekstowej:
:: main comment
treestructinfo "2.0"
:: some data
attr Name "furious"
attr Second "programming"
:: subnode
node Tags
attr 0 "pascal"
attr 1 "delphi"
attr 2 "tsinfo"
end node
end tree
a tak w postaci binarnej (to samo drzewko, te same dane, pełna kompatybilność):
TREESTRUCTINFO..........main comment.........Name....furious....some data.........Second....programming.................Tags....subnode.............0....pascal.............1....delphi.............2....tsinfo............
Forma tekstowa jest czytelna i da się nią bez problemu edytować w dowolnym notatniku. Forma binarna wygląda na tyle nieczytelnie, że nie da się tego drzewka łatwo zmodyfikować (nawet w hex-edytorze), pomimo tego, że w dalszym ciągu zawiera dane plaintextem.
Różnica jest taka, że w przypadku tekstowej formy, program musi parsować linijka po linijce całą zawartość pliku, tracąc czas na odsiewanie cukru składniowego (wcięć, słów kluczowych, białych znaków, cudzysłowów) i wydłubywanie właściwych danych.
Forma binarna nie musi tego robić – po prostu czyta kolejne porcje danych (bo zna ich rozmiar) i ładuje je pakietami do pamięci, bez absolutnie żadnej obróbki (dlatego jest znacznie szybsza).
Szalony Krawiec napisał(a):
Wydaje się, że kolega po prostu nie wiedział, że są już gotowe formaty zapisu takich danych tekstowo (xml, xsd) i binarnie (sqlite) i świat z nich korzysta, albo w Lazarusie nie było dobrych komponentów do ich obsługi, więc postanowił napisać swój format.
Przeczytaj ten wątek od początku a dowiesz się dlaczego opracowałem ten format.
Oczywiście to ogrom pracy, ale nierealne jest prześcignąć istniejące analogiczne rozwiązania, to chyba nigdy nie było celem
Tak, nigdy nie chciałem, aby mój projekt zrewolucjonizował świat. :]
Biały Lew1 napisał(a):
No ale masz format binarny w tej twojej bibliotece. Skoro sqlite to też format binarny, a do tego szybszy niż format binarny twojej biblioteki, to w zasadzie jaki tu sens...
Erm, niby jak chcesz trzymać konfigurację w SQLite? Chcesz porobić dziesiątki tabelek gdzie większość będzie miała limit jednego wiersza? Jak wyciągać potem dane z tego SQLite? W przypadku konfiguracji mam np: config.getStrings("server.upload.allowed_extensions"). Jakie będzie analogiczne zapytanie SQL do wyciągnięcia tego pola?
Binarny format dla konfiguracji to tylko opcja jak wspomniał @furious programming dla przyspieszania szybkości ładowania bądź przesyłania pliku. W przypadku SQLite tak naprawdę też masz opcję zamiany między formatem tekstowym, a binarnym. Wystarczy robić eksport bazy do SQLa, a potem import. Tego SQLa możesz sobie edytować w jakimś notatniku, ale to nie będzie mieć sensu. Sens ma trzymanie konfiguracji w formacie przeznaczonym do trzymania konfiguracji.
Przykładowy scenariusz wykorzystania formatów tekstowych i binarnych dla konfiguracji:
Wibowit napisał(a):
Binarny format dla konfiguracji to tylko opcja jak wspomniał @furious programming dla przyspieszania szybkości ładowania bądź przesyłania pliku.
I to w sumie tyle – serializacja i deserializacja ma być szybsza, pliki przy okazji ważą mniej.
Po załadowaniu konfiguracji do pamięci, pojęcie formy przestaje istnieć, bo reprezentowana jest przez ujednolicone natywne drzwko i obsługiwana jest przez tę samą klasę. Forma ma znaczenie wyłącznie jeśli chodzi o plik, listę lub strumień, czyli poza biblioteką do obsługi tego formatu.
furious programming napisał(a):
Forma tekstowa jest czytelna i da się nią bez problemu edytować w dowolnym notatniku. Forma binarna wygląda na tyle nieczytelnie, że nie da się tego drzewka łatwo zmodyfikować (nawet w hex-edytorze), pomimo tego, że w dalszym ciągu zawiera dane plaintextem.
Jeżeli zawiera dane plaintextem, to jest dalej forma tekstowa, tyle że inna. Nie masz więc żadnej formy binarnej, masz 2 różne formaty tekstowe.
furious programming napisał(a):
Forma binarna nie musi tego robić – po prostu czyta kolejne porcje danych (bo zna ich rozmiar) i ładuje je pakietami do pamięci, bez absolutnie żadnej obróbki (dlatego jest znacznie szybsza).
Jeśli do tych plików konfiguracyjnych wrzucasz tak dużo danych, że "odsiewanie cukru składniowego" powoduje narzut zauważalny dla użytkownika, to znaczy że próbujesz używać pliku konfiguracyjnego tak jak systemu bazodanowego właśnie (terminologię chyba znasz, skoro wklejasz linki), co jest z gruntu złe. Plik konfiguracyjny, jak sama nazwa wskazuje, powinien być używany do zapisywania konfiguracji, a nie jakichś dużych porcji danych, do tego (jak znów sama nazwa wskazuje, wymyślono bazy danych,).
Nie chcę już dłużej pastwić się nad tobą, bo wyjdę na hejtera a nie o to mi chodzi.
Biały Lew1 napisał(a):
Jeżeli zawiera dane plaintextem, to jest dalej forma tekstowa, tyle że inna. Nie masz więc żadnej formy binarnej, masz 2 różne formaty tekstowe.
Co za bzdury odpowiadasz… jaka druga tekstowa? Kto normalny tworzy pliki tekstowe i pakuje do nich NULL-e albo inne znaki kontrolne, inne niż CR, LF czy TAB? A takie właśnie znaki zawierają wszystkie binarne pliki tsinfo, w większej lub mniejszej ilości.
Nie chce mi się dalej tego komentować, bo twoje odpowiedzi wyglądają tak, jakbyś nie rozumiał różnicy pomiędzy plikami konfiguracyjnymi a bazami danych. Jedno od drugiego odróżnia tak wiele, że nawet nie ma się nad czym zastanawiać.
Wibowit napisał(a):
Biały Lew1 napisał(a):
No ale masz format binarny w tej twojej bibliotece. Skoro sqlite to też format binarny, a do tego szybszy niż format binarny twojej biblioteki, to w zasadzie jaki tu sens...
Erm, niby jak chcesz trzymać konfigurację w SQLite? Chcesz porobić dziesiątki tabelek gdzie większość będzie miała limit jednego wiersza? Jak wyciągać potem dane z tego SQLite? W przypadku konfiguracji mam np: config.getStrings("server.upload.allowed_extensions"). Jakie będzie analogiczne zapytanie SQL do wyciągnięcia tego pola?
Wystarczy jedna tabela, z 2 kolumnami nazwa i wartość. Wyciągasz dane jednym selectem. Naprawdę, patrząc po twoich postach, nie jesteś chyba idiotą, czemu więc zadajesz tak idiotyczne pytania?
P.S. nie namawiam do rezygnowania z plików konfiguracyjnych na rzecz sqlite, wszystko zależy od konkretnej sytuacji. Czasem lepiej w sqlite, czasem nie ma to sensu.
Jeżeli zawiera dane plaintextem, to jest dalej forma tekstowa, tyle że inna. Nie masz więc żadnej formy binarnej, masz 2 różne formaty tekstowe.
Jak wstawię tekst do bazki SQLite to przy podejrzeniu jej notatnikiem zobaczę ten tekst w całej okazałości. Czy to znaczy, że bazka SQLite jest trzymana w postaci tekstowej?
Plik konfiguracyjny, jak sama nazwa wskazuje, powinien być używany do zapisywania konfiguracji, a nie jakichś dużych porcji danych, do tego (jak znów sama nazwa wskazuje, wymyślono bazy danych,).
A sam proponowałeś używanie SQLite do trzymania konfiguracji.
Konfigi czasem ważą i po sto kilobajtów, ale to i tak jest wartość na tyle mała, by parsowanie tego było bardzo szybkie. Jednak dla sportu można sobie zaimplementować ten format binarny. Prawdopodobnie zaimplementowanie go nie było szczególnie trudnym wyzwaniem, a raczej przyjemnym ćwiczeniem.
Konfig jest używany zdecydowanie inaczej niż baza danych. Bazy danych są zorientowane głównie pod wyciąganie niewielkich zbiorów danych jednym zapytaniem, natomiast ładowanie konfiga ładuje go w całości (podobnie zapis oznacza nadpisanie całego pliku z danymi). Używając SQLite musiałbyś albo robić setki zapytań, by zrobić to co robi się jednym parsowaniem konfiga albo skonstruować monstrualne zapytanie SQL do wyciągania zawartości całej bazki naraz. Oba rozwiązania nie rokuje dobrze jeśli chodzi o wydajność.
furious programming napisał(a):
Biały Lew1 napisał(a):
Jeżeli zawiera dane plaintextem, to jest dalej forma tekstowa, tyle że inna. Nie masz więc żadnej formy binarnej, masz 2 różne formaty tekstowe.
Co za bzdury odpowiadasz… jaka druga tekstowa? Kto normalny tworzy pliki tekstowe i pakuje do nich
NULL-e albo inne znaki kontrolne, inne niżCR,LFczyTAB? A takie właśnie znaki zawierają wszystkie binarne pliki tsinfo, w większej lub mniejszej ilości.Nie chce mi się dalej tego komentować, bo twoje odpowiedzi wyglądają tak, jakbyś nie rozumiał różnicy pomiędzy plikami konfiguracyjnymi a bazami danych. Jedno od drugiego odróżnia tak wiele, że nawet nie ma się nad czym zastanawiać.
No to ty zapoznaj się z terminologią. Twierdzisz, ze plik zawiera dane zapisane plaintekstem, a potem mówisz ze pchasz tam Nulle. Wiesz co to jest plaintekst?
Wystarczy jedna tabela, z 2 kolumnami nazwa i wartość. Wyciągasz dane jednym selectem. Naprawdę, patrząc po twoich postach, nie jesteś chyba idiotą, czemu więc zadajesz tak idiotyczne pytania?
P.S. nie namawiam do rezygnowania z plików konfiguracyjnych na rzecz sqlite, wszystko zależy od konkretnej sytuacji. Czasem lepiej w sqlite, czasem nie ma to sensu.
Wycieczki osobiste mogłeś sobie darować.
Tak się składa, że z bazkami SQL jak i z bibliotekami do konfigów miałem dużo do czynienia i nie widzę sensu w ogóle trzymania konfiguracji w bazce. To jest strasznie toporne rozwiązanie. W ogóle co mi z tego, że zrobię tabelę z dwiema kolumnami? To już jest zupełnie bez sensu. Nie lepiej zrobić plik typu INI z linijkami typu "klucz=wartość"? Rozmiar miałoby nawet mniejszy niż bazka SQLite, dane wyciągałoby się też szybciej, a nie trzeba byłoby się pałować z integrowaniem SQLite z aplikacją.
Pokaż mi konkretne porównania między korzystaniem z API biblioteki do obsługi konfiguracji, a własnym rozwiązaniem opartym o SQL. Jestem tego ciekaw.
Dane zawiera plaintekstem – dane takie jak komentarze, identyfikatory i wartości atrybutów.
Reszta zapisywana jest binarnie, są to liczby określające wersję formatu, długości wszystkiego co plaintekstem (ciągi komentarzy, identyfikatorów i wartości atrybutów), liczby atrybutów i węzłów potomnych.
Jesus Christ…
@Wibowit wyjaśnię ci jeszcze raz. Plik zapisany plaintekstem to taki, który zawiera tylko i wyłącznie plain tekst. Czy to tak ciężko pojąć? Czy jak otworzysz plik sqlite w notatniku, to zobaczysz tam czysty plain tex?
P.S. przecież już wspominałem, że wszystko zależy od konkretnej sytuacji i nie namawiam do rezygnacji z configów xml na rzecz sqlite.
P.S. przecież już wspominałem, że wszystko zależy od konkretnej sytuacji i nie namawiam do rezygnacji z configów xml na rzecz sqlite.
Ale pokaż ten sposób użycia SQLite'a. Podałeś go jako coś oczywistego, więc nie powinno być dla ciebie problemem rozwinięcie tematu, no nie?
Konfiguracja działa zwykle tak, że na starcie programu ładuję cały konfig do pamięci. Przy zmianie ustawień programu zapisuję konfig na dysk (w całości).
Biały Lew1 napisał(a):
@Wibowit wyjaśnię ci jeszcze raz. Plik zapisany plaintekstem to taki, który zawiera tylko i wyłącznie plain tekst. Czy to tak ciężko pojąć? Czy jak otworzysz plik sqlite w notatniku, to zobaczysz tam czysty plain tex?
A czy jak otworzysz binarny plik tsinfo to zobaczysz tam goły tekst? Nie, zobaczysz to:
Jak widać dane są plaintekstem, ale tylko dane (i przy okazji nagłówek).
furious programming napisał(a):
Dane zawiera plaintekstem – dane takie jak komentarze, identyfikatory i wartości atrybutów.
Reszta zapisywana jest binarnie, są to liczby określające wersję formatu, długości wszystkiego co plaintekstem (ciągi komentarzy, identyfikatorów i wartości atrybutów), liczby atrybutów i węzłów potomnych.
Jesus Christ…
No to w końcu wyartykułowałeś o co ci chodzi. Aczkolwiek, albo twój parser składni jest bardzo powolny, albo masz naprawdę wielkie pliki konfiguracyjne, jeśli różnica jest mocno odczuwalna. W drugim przypadku i tak upierałbym się raczej na wepchnięcie danych do bazy (jeśli jest ich tak dużo), a czy te dane to konfiguracja aplikacji czy nie, to sprawa drugorzędna w tym wypadku.
Wibowit napisał(a):
P.S. przecież już wspominałem, że wszystko zależy od konkretnej sytuacji i nie namawiam do rezygnacji z configów xml na rzecz sqlite.
Ale pokaż ten sposób użycia SQLite'a. Podałeś go jako coś oczywistego, więc nie powinno być dla ciebie problemem rozwinięcie tematu, no nie?
Konfiguracja działa zwykle tak, że na starcie programu ładuję cały konfig do pamięci. Przy zmianie ustawień programu zapisuję konfig na dysk (w całości).
Podałem to jako coś oczywistego w kontrze do formatu binarnego tsinfo. Dla normalnej konfiguracji programu masz rację, nie ma sensu sqlite, ale tak samo nie ma zbytniej potrzeby stosowania formatu binarnego tsinfo (już wiem, na czym polega), bo różnica wydajności powinna byc niezauważalna, a plików nie będzie można edytować poza aplikacją.
W drugim przypadku i tak upierałbym się raczej na wepchnięcie danych do bazy (jeśli jest ich tak dużo), a czy te dane to konfiguracja aplikacji czy nie, to sprawa drugorzędna w tym wypadku.
Konfigurację ładuje się w całości w jednym momencie. Analogicznie zapis konfiguracji polega na zastąpieniu poprzedniego pliku z konfiguracją. Po co używać bazy danych jeśli i tak ładujemy bądź nadpisujemy wszystkie dane naraz? Jaki to da zysk?
P.S. pomyśl jeszcze o tym, że nie zawsze musisz chcieć ładować do pamięci cały config. Może czasem warto zmodyfikować tylko jeden parametr, zamiast ładować ich 500 do jakiejś złożonej struktury. Są takie specyficzne przypadki.
Nie znam takich przypadków.
Opcjonalny binarny format konfiga można potraktować jako niewiele znaczącą ciekawostkę, ale ładowanie konfiga do bazy SQL to już dla mnie wygląda na masochistyczny absurd. Tyle z mojej strony :] No chyba, że masz jakiś przekonujący przykład z życia wzięty...