Na official sqlite3 web page napisano, że powinienem myśleć o sqlite jako zamienniku funkcji fopen().Sqlite jako zamiennik dla fopen()?
Co o tym sądzisz? Czy zawsze dobrym rozwiązaniem jest zamiana wewnętrznego magazynu danych aplikacji na sqlite? Jakie są plusy i minusy takiego rozwiązania?
Czy masz w tym jakieś doświadczenie?
EDYTOWANIE: Co ze swoim doświadczeniem? Czy to jest łatwe w obsłudze? Czy było to bolesne, czy raczej radosne? Czy lubisz to?
To zależy. Istnieją pewne przeciwwskazania:
dla plików konfiguracyjnych, stosowanie zwykłego tekstu lub XML jest znacznie łatwiejsze do debugowania lub zmienić niż przy użyciu relacyjnej bazy danych, nawet tak lekka jak SQLite.
struktury drzewa są łatwiejsze do opisania za pomocą (na przykład) niż XML za pomocą tabel relacyjnych
SQLite API jest całkiem źle udokumentowane - nie ma wystarczająco dużo przykładów i linkowania jest słaba. OTOH, wszystkie informacje są dostępne, jeśli chcesz je znaleźć.
wykorzystanie aplikacji specyficznych formatów binarnych bezpośrednio będzie szybsze niż przechowywanie sam format jako BLOB w bazie danych
bazy danych z korupcją może oznaczać LOS wszystkie twoi zamiast danych, które w jeden zły złożyć
OTOH, jeśli dane wewnętrzny pasuje dobrze do modelu relacyjnego, a jeśli nie ma aa dużo, polecam SQLite - używam go sobie dla jednego z moich projektów.
Jeśli chodzi o doświadczenie - używam go, działa dobrze i jest łatwy do zintegrowania z istniejącym kodem. Gdyby dokumentacja była łatwiejsza w nawigacji, dałbym jej 5 gwiazdek - tak jakbym dał jej cztery.
Atomowość SQLite to plus. Wiedząc, że jeśli w połowie napiszesz jakieś dane (może się zdarzyć w środku), to nie uszkodzi twojego pliku danych. Zwykle robię coś podobnego w plikach konfiguracyjnych xml, wykonując kopię zapasową pliku po pomyślnym załadowaniu, a wszelkie przyszłe nieudane obciążenia (wskazujące uszkodzenie) automatycznie przywracają ostatnią kopię zapasową. Oczywiście nie jest tak ziarnisty, ani atomowy, ale wystarczający dla moich pragnień.
To prawda, spróbuj "prawidłowego" sposobu utworzenia kopii zapasowej istniejącego pliku danych i napisania nowego w taki sposób, aby nie można było zawieść w żadnym momencie. –
Jaki byłby "właściwy" sposób według Ciebie? – AaronLS
Jak zawsze to zależy, nie ma „jeden rozmiar dla wszystkich” rozwiązań
Jeśli trzeba przechowywać dane w pliku stand-alone i można skorzystać z relacyjnych możliwości bazy danych bazy danych SQL, niż SQLite jest super.
Jeśli twoje dane nie pasują do modelu relacyjnego (np. Dane hierarchiczne) lub chcesz, aby dane były czytelne dla człowieka (pliki konfiguracyjne) lub musisz współpracować z innym systemem, niż SQLite nie będzie bardzo pomocne i XML może być lepszy.
Jeśli z drugiej strony potrzebujesz dostępu do danych z wielu programów lub komputerów jednocześnie, SQLite nie jest optymalnym wyborem i potrzebujesz "prawdziwego" serwera baz danych (MS SQL, Oracle, MySQL, PosgreSQL ...).
Uważam, że praca z SQLite jest przyjemnością, ale nie uważam tego za jedyny w swoim rodzaju zamiennik fopen().
Jako przykład, napisałem właśnie kawałek oprogramowania, które pobiera obrazy z serwera sieciowego i buforuje je lokalnie. Przechowując je jako pojedyncze pliki, mogę je oglądać w Eksploratorze Windows, co z pewnością przynosi korzyści. Ale potrzebuję zachować indeks, który mapuje między adresem URL a plikiem obrazu, aby móc korzystać z pamięci podręcznej. Przechowywanie ich w bazie danych SQLite, wszystkie znajdują się w jednym, zgrabnym, małym pliku i mogę uzyskać do nich dostęp poprzez adres URL (wybierz imgdata z pamięci podręcznej, gdzie url = "http://foo.bar.jpg") przy niewielkim wysiłku.
Źle udokumentowane? Myślę, że jest naprawdę dobry w porównaniu do innych projektów FOSS. Wymieniają warunki wstępne i końcowe dla wszystkiego i nie miałem problemu ze zrozumieniem API - z jednym wyjątkiem. (Jeden z ich warunków ma ładną małą nutę "todo", że muszą ustalić, co robi). – jalf
O korupcji bazy danych, można po prostu podzielić dane na oddzielne bazy danych. Korupcja własnych plików byłaby równie zła - i bardziej prawdopodobna. Bazy danych są zaprojektowane tak, aby były trwałe i trwałe. Ale zgadzam się z ogólną uwagą. – jalf
@jalf nie ma prawie żadnych przykładów - grzech kardynalny dla mnie, o ile dokumentacja idzie. Również hiperłącze jest bardzo słabe. –