Czy SQLite nie jest trochę niedoceniane? [Zamknięte]

Zanim zadam pytanie, pozwól mi najpierw opisać swoje przemyślenia na temat SQLite.

Zdarza mi się lubić narzędzia, które są małe, szybkie i, co ważniejsze, mają tylko naprawdę niezbędną funkcjonalność. Dlatego lubię SQLite i trochę mniej MS-SQL.

Na przykład: MS-SQL może mieć znacznie większą funkcjonalność, skalowalność itp. Itd., Ale może być również trudny do zainstalowania, jeśli masz pecha. Oczywiście nie twierdzę, że trudna instalacja jest powodem, aby nie wybierać konkretnej bazy danych.

Nie zrozum mnie źle: MS-SQL jest produktem wysokiej jakości. Mam duże doświadczenie z MS-SQL; Bardzo dobrze rozumiem ten produkt jako profesjonalista. Po prostu wolę go mniej w pewnych okolicznościach, w których nie jest tak naprawdę potrzebny (= niewielu użytkowników, <10-15).

Ile funkcji bazy danych naprawdę używasz? Z mojego doświadczenia wynika, że ​​często jest to zwykły SQL (SELECT, INSERT i UPDATE).

Lubię SQLite. Fascynuje szybko. „Instalacja” jest niezwykle łatwa. Myślę, że SQLite może zrobić więcej, niż twierdzi. Dlaczego warto go używać tylko do aplikacji jednoprocesowych / dla pojedynczego użytkownika? W końcu: niewiele aplikacji stale uzyskuje dostęp do bazy danych.

Na przykład: rozważ aplikację ERP z, powiedzmy, 15 użytkownikami. Dlaczego nie można do tego użyć SQLite? Spójrzmy prawdzie w oczy: z mojego doświadczenia zawodowego użytkownicy tego typu aplikacji będą uzyskiwać dostęp do bazy danych przez około 5-10% całkowitego czasu korzystania z aplikacji. W pozostałych 90–95% po prostu oglądają informacje na ekranie, wprowadzają dane w siatce / formie, a kiedy zapisują swoje dane, nie przekracza to 1 sekundy czasu bazy danych. Fe: 1,5 minuty czasu wejściowego vs. 1 sekunda czasu oszczędzania.

Jeśli plik bazy danych SQLite jest zablokowany podczas „oszczędzania czasu”, inni użytkownicy, którzy potrzebują dostępu do bazy danych, po prostu czekają, ale nie zauważają tego, ponieważ czas oczekiwania będzie bardzo krótki (niezauważalny). W kodzie wystarczy poradzić sobie z możliwym „zajętym” czasem bazy danych, aby uniknąć wyjątków, ale nie jest to trudne.

Jakiś facet, który musi myśleć tak samo jak ja, zbudował nawet rozwiązanie klient-serwer dla SQLite: SQLitening . To mnie bardziej przekonało, że sam siebie nie oszukuję.

Oczywiście istnieją aplikacje intensywnie korzystające z baz danych, w których SQLite nie pasuje. Ale jak teraz o tym myślę, wiele aplikacji dla wielu użytkowników, jeśli nie przekracza 15 użytkowników, powinno dobrze działać z SQLite.

Wielu naszych klientów nie wydaje dużo na sprzęt, więc często spotykam się z jednym serwerem ze wszystkim na nim (Exchange, SQL (s), klienci itp.) I z tego powodu są prawie „bez tchu”. Gdybym mógł dostarczyć produkt, który nie ma wysokich wymagań systemowych, mój klient byłby zadowolony. SQLite nie dodaje żadnej wagi (przynajmniej niewiele), MS-SQL robi. Nie wybrałbym więc SQLite, ponieważ jest darmowy, tani lub łatwy w instalacji. Wybrałbym to ze względów praktycznych / technicznych.

FYI: W moim zawodzie sprzedajemy produkty (niestandardowe i standardowe, głównie związane z ERP) klientom, z których średnio nie będzie korzystało więcej niż 5-6 osób. Istnieją pewne wyjątki, ale nie więcej niż 10-15 użytkowników.

Pytanie brzmi: czy mam rację sądząc, że mogę używać SQLite do niektórych aplikacji dla wielu użytkowników, takich jak opisany przeze mnie przykład? Czy są jakieś wady techniczne, o których powinienem wiedzieć? Jakie są twoje doświadczenia (negatywne lub pozytywne), które pomogą mi dokonać właściwego wyboru?

Aktualizacja: nie postrzegaj tego jako negatywnej oceny innych baz danych. W większości są to dobre produkty. Po prostu dzielę się swoimi przemyśleniami tutaj i jestem zainteresowany twoimi opiniami na ten temat.

Istnieje wiele przypadków, w których SQLite jest dużo. Użytkownik, dział lub firma rzadko go przerastają (nie słyszymy o tym zbyt często, ponieważ nikt nie dzwoni do programisty, jeśli aplikacja działa dobrze). Można to samo argumentować za plikiem MS Access (Windows) lub SQL Server Compact Edition (wymagana instalacja). Wszystkie są wystarczająco dobre dla aplikacji lokalnej, ponieważ nie musisz martwić się o bezpieczeństwo pliku.

W scenariuszu z wieloma użytkownikami w sieci lokalnej plik trafia do folderu współdzielonego, do którego wszyscy użytkownicy będą potrzebować dostępu - zabezpieczenia połączeń. Prosta konserwacja lub wszelkie zmiany struktury tabeli, takie jak kopie zapasowe lub dodanie kolumny, uniemożliwiają innym użytkownikom dostęp. Ostatniej nocy kopia zapasowa nie działała, ponieważ ktoś zapomniał zamknąć aplikację. Co dzieje się, gdy chcesz wykonać kopię zapasową w środku dnia? Wszyscy racjonalizują, że nie potrzebują żadnych kopii zapasowych w ciągu dnia z powodu ograniczeń technicznych ich bazy danych. W pewnym momencie instalacja SQL Server Express / inny odpowiednik na serwerze zajmie trochę początkowej konfiguracji i konfiguracji bezpieczeństwa, jest bardziej zaangażowana z góry, ale nie będzie wymagać konserwacji.

Zawsze istnieje obawa o skalowalność / nadmierną inżynierię. Nawet jeśli liczbą użytkowników lub ilością danych nadal można zarządzać, ktoś zawsze ma pomysł wykorzystania danych na żywo w jakimś intranecie lub innym interfejsie strony / przeglądarki. Plikowe bazy danych stwarzają problemy. Wystarczy jedna osoba, która chce uzyskać dostęp do pliku danych przez VPN (aplikacja jest zainstalowana na swoim laptopie), aby dać ci problem z „skalowaniem”. Możesz zbudować aplikację, aby umożliwić rozłączonym użytkownikom, którzy mogą synchronizować po powrocie. Po prostu nie wydaje się tego warte dla okazjonalnego użytkownika spoza biura.

Myślę, że świetnie jest go używać, gdy potrzebujesz „wewnętrznej” bazy danych. Oznacza to, że baza danych, z którą będzie współpracować twoja aplikacja / kod, ale nie będzie to bezpośrednio związane z głównym powodem, dla którego twoja aplikacja istnieje. Zamiast używać ogromnych mapowań w pamięci lub menedżerów pamięci podręcznej, równie dobrze możesz na przykład użyć takiej bazy danych. Mam bardzo konkretny przykład tego, ponieważ ostatnio użyłem go w przypadkach testowych JUnit / DBunit, w których musiałem połączyć się z bazą danych, wykonać trochę pracy, odczytać dane i usunąć wszystko na końcu. Ponieważ wystarczy utworzyć pusty plik, aby utworzyć bazę danych , było to dość łatwe do zrobienia.

Kolejne użycie widzę: gdy masz tylko jednego użytkownika. Tak, to możliwe, pomyśl na przykład „Firefox” lub „Opera” :-)

Ponadto na stronie SQLite są bardzo szczerzy i podają powody, dla których NIE NALEŻY KORZYSTAĆ (patrz akapit „Sytuacje, w których inny RDBMS może działać lepiej”)

ps: związany z komentarzami do Sql Server Express, tak, należy go „zainstalować”. I miałem pewne problemy z aktualizacją go osobiście (musiałem ręcznie usunąć niektóre klucze rejestru związane z poprzednią wersją, aby móc zainstalować 2008 R2). Jeśli jednak chcesz porównać SQLite z bazą danych opracowaną przez Microsoft, spójrz na Sql Server Compact Edition , którego nie musisz instalować (patrz „wdrożenie oparte na plikach prywatnych”).

Na przykład: rozważ aplikację ERP z, powiedzmy, 15 użytkownikami. Dlaczego nie można do tego użyć SQLite?

Bardzo niewiele aplikacji ma tak mało użytkowników na zawsze. I dla wszystkiego, co widzi więcej użytkowników i bardziej złożone manipulowanie danymi, używanie SQLite jest całkowicie wykluczone ze względu na wydajność ze względu na prosty model blokowania „jedna operacja zapisu na raz”.

Załóżmy, że masz 100 użytkowników, z których każdy pracuje przez 60 sekund, wypełniając formularz i przesyłając go. Musisz więc przetworzyć około 1,6 transakcji na sekundę. Model danych jest złożony, a zapisanie formularza wymaga odczytu i zapisu do wielu dużych tabel, być może nawet komunikacji z innym systemem, więc każde „przesłanie formularza” powoduje transakcję, która zajmuje 2 sekundy. Ale SQLite nie może przetwarzać transakcji jednocześnie, więc oznacza to, że może przetwarzać tylko 0,5 transakcji na scond. Ups

„Instalacja może być uciążliwa” nie jest dobrym powodem, aby zdecydować się na krytyczny element infrastruktury. Poza tym istnieją inne silniki DB do wyboru, z których co najmniej dwa (MySQL i Postgres) są bezpłatne i nie mają ograniczeń współbieżności SQLite. Mogą być nawet łatwiejsze do zainstalowania niż MS-SQL.

Myślę, że SQLLite jest doskonały do ​​tworzenia aplikacji, jego największą zaletą jest to, że nie trzeba go instalować na kliencie.

Jednak nie lekceważ też SQL Server Express, jest to darmowa doskonała baza danych z większością funkcji zwykłego serwera SQL z jedynie ograniczeniem wielkości bazy danych (którą trudno jest przekroczyć) wraz z możliwością korzystania z doskonałych narzędzi normalnego serwer sql.

Największym minusem jest to, że musisz go zainstalować. Nie jestem pewien, czy ta część może być teraz

Nie uważam SQLite za poważną bazę danych, jeśli masz do czynienia z kilkoma GB danych co godzinę. Robi się boleśnie powolny i obniża wydajność całej aplikacji. Przepraszamy, ale nie zgadzam się z twoją fascynacją SQLite :-)

Problem z bazami danych polega na tym, że gromadzą one coraz więcej danych. Wybór lekkiej bazy danych stwarza ryzyko, że twoje narzędzie nie będzie poprawnie skalować.