Dlaczego SQLite nie jest "prawdziwym" SQL?
Mam nadzieję, że nie jest to czepianie się słówek i dowalanie się do tego, że użyłem skrótu myślowego :P
Chodziło mi o to, że SQLite to taka jednak wersja uproszczona "prawdziwej" bazy. OK, sam nieraz z niego korzystam i sobie cenię jego prostotę, ale faktem jest, że w pewnych okolicznościach sobie średnio radzi. I żeby nie było, że wymyślam - są to informacje z ich strony https://www.sqlite.org/whentouse.html:
- architektura klient-serwer:
If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite
- obsługa wielu zapisów jednocześnie:
SQLite only supports one writer at a time per database file
ponadto:
- brak replikacji/mirrorowania
- brak uprawnień dostępowych - każdy, kto ma dostęp do bazy, może z nią zrobić cokolwiek. Oczywiście - można powiedzieć, że bazę trzeba zabezpieczyć, ale faktem jest, że w realnych aplikacjach stosuje się systemy uprawnień, żeby w razie jakiejś kompromitacji użytkownik mógł nagrzebać jedynie w tym, do czego ma dostęp, czyli np. user nie dostanie się do danych przeznaczonych dla administratora. A przy SQLite, jeśli znajdziesz dziurę w systemie (np. brak zabezpieczeń w jakimś skrypcie PHP), to nic już Cię nie powstrzyma, baza sama się nie obroni.
@Patryk27 - co do atomowości takiego backupu - czyli potwierdziłeś moje podejrzenia/przypuszczenia. Czy jest jeszcze jakiś argument na rzecz dump zamiast skopiowania pliku?
Powiedzmy masz w pliku 10 tabel, a tylko 2 z nich użyszkodnicy psują i trzeba odtwarzać. Natomiast pozostałe mają być na bieżąco. Więc co ci da plik?
@_13th_Dragon - tutaj masz rację, jeśli chcesz tylko wybraną część bazy backupować to tak, korzystanie z dump ma sens. Ale mi nie chodzi o naprawianie bazy po działaniach userów, tylko o zabezpieczenie na wypadek awarii (np. padnięty dysk czy przypadkowe skasowanie).