SQLite musi zginąć (przynajmniej kilka jego aspektów)
Dawno nie pisałem - ale cóż - nie mam za dużo czasu.
SQLite w zamierzeniu jest dobrym pomysłem. Wiele aplikacji potrzebuje bazy danych ale nie potrzebuje mieć całego bagażu (typu obsługa wielu sesji naraz) bazy danych typu MySQL czy PostgreSQL - jedna z rzeczy, która mi się niespodobała w MythTV to konieczność instalacji MySQL (wolę PostgreSQL). Jednak SQLite ma kilka problemów, które są dla mnie dość denerwujące.
Kto potrzebuje bezpieczeństwa typów?
Miałem taki kod:
- CREATE TABLE test1 (
- test_field INTEGER NOT NULL
- );
Pytanie - czy to zadziała:
INSERT INTO test1 VALUES ("test");
Odpowiedz brzmi tak. Co z tego, że:
- Utrudnia to szukanie błędów (nie przyszło mi do głowy, że jak określiłem mu typ to on nie sprawdzi tego)
- Zwiększa zapotrzebowanie na pamięć (powinno zajmować 4 bajty a zajmuje 4 bajty + opis typu)
- Utrudnia to pisanie aplikacji przenośnych między bazami danych (używałem SQLite do rozwijania programu - trochę się zdziwiłem gdy próbowałem uruchomić aplikację na PostgreSQL).
Jeśli pierwszy i trzeci punkt sprawiają za duże nakłady CPU/MEM to nich będzie przynajmniej tryb 'devel'/'strict' czy jakoś tak...
Po co usuwać/zmieniać kolumny?
Skoro można coś zrobić inaczej to po co 'zaśmiecać' język pełnymi operacjami? Np. Załóżmy, że mamy tabelę:
- CREATE TABLE test2 (
- id INTEGER PRIMARY KEY,
- id2 INTEGER PRIMARY KEY
- );
I chcemy zmienić id na id1. Wykonujemy kilka 'prostych' operacji:
- ALTER TABLE test2 RENAME TO test2_old;
- CREATE TABLE test2 (
- id1 INTEGER PRIMARY KEY,
- id2 INTEGER PRIMARY KEY
- );
- INSERT INTO test2 (id1, id2)
- SELECT id, id2 FROM test2_old;
- DROP TABLE test2_old;
I po co komu:
ALTER TABLE test2 RENAME COLUMN id TO i2
W końcu narzut na kopiowanie danych jest niewielki...
Błąd w składni? Nie przejmuj się.
Błędy są rzeczą ludzką. Ale należy je naprawiać a nie pielęgnować. Np. czy taki kod zadziała:
- CREATE TABLE test3 (
- id TEST I HAVE WRITTEN SOMETHING HERE HEY
- );
Odpowiedz brzmi - tak. Nie pojawi się nawet żadene ostrzeżenie... Problemy jakie może sprawić rozróżnienie (każda baza danych stosuje swoją pisownie):
AUTOINCREMENT
AUTO INCREMENT
AUTO_INCREMENT
przekraczają sprawdzenie, co parser przełknie...
Podsumowanie
Chciałbym zaznaczyć - nie potrafiłbym napisać lepszej bazy danych niż SQLite. Wydaje mi się, żę tych kilka usterek przydałoby się naprawić - co nie znaczy że ta baza danych nie nadaje się do całej masy dziedzin. Tekst ten wskazuje i ma wskazywać na błędy (w mojej opinii) SQLite i nie powinien być uznany za całościowe stadiuum tej biblioteki/programu.
Komentarze do wpisu
Możesz śledzić odpowiedzi poprzez kanał RSS. Możesz dodać komentarz lub zostawić ślad (trackback) ze swojego bloga.
Khorne
1. „SQLite is typeless. All data is stored as null-terminated strings. This is feature, not a bug”. Prawdopodobnie silne typowanie można uzyskać za pomocą więzów, ale nie sprawdzałem.
2. czepialstwo ;)
3. zgłosiłeś buga?
18 czerwca 2008, 16:43:58
Uzytkownik
1. Wspaniały feature. A potem odkrywam błąd jak próbuje portować na inne bazy danych. Gdybym chciał mieć to zachowanie to używałbym kolumn typu String samemu…
2. Wspaniale. Tylko że tego akurat potrzebowałem…
3. Pewnie chodzi o dopuszczenie rozszerzeń języka (w C) – więc parser tego nie wychwytuje.
18 czerwca 2008, 19:40:47
Dodaj komentarz