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

15

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.


źródło
9
Przepraszam, ale dodajesz „Czy mam rację?” nie zamienia zdania w pytanie.
pdr
1
@pdr: Dlaczego uważasz to za rant? Nie oceniam negatywnie MS-SQL ani innych baz danych; w większości są to dobre produkty. Po prostu dzielę się przemyśleniami i chciałbym poznać opinie innych programistów. Nic dodać nic ująć.
3
Nie ma tu pytania, tylko wyszukiwanie walidacji. Z FAQ: „Powinieneś zadawać tylko praktyczne, możliwe do odpowiedzi pytania oparte na rzeczywistych problemach, z którymi się stykasz. Rozmowne, otwarte pytania zmniejszają użyteczność naszej strony i odsuwają inne pytania od pierwszej strony”. programmers.stackexchange.com/faq
pdr
1
@pdr: Rozumiem to, ale szczerze mówiąc chciałem tutaj zadać pytanie. Może nie byłem jasny, więc sformułowałem pytanie.
4
Wybór bazy danych, optymalizacja kodu, aplikacja kliencka, serwerowa lub internetowa - to wszystkie kwestie do rozważenia, a zalety i wady należy omówić na takiej platformie. Dla mnie rantem jest więcej, gdy ktoś kategorycznie odmawia znalezienia jakiejkolwiek zbawczej jakości w określonej technologii.
JeffO

Odpowiedzi:

8

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.

JeffO
źródło
Można podać ten sam argument dla SQL Server Compact Edition, ale nie dla bazy danych MS Access. Dostęp do baz danych jest traktowany jak prawdziwa baza danych, ale działa bardziej jak udostępnione pliki. Są delikatnym rozwiązaniem; SQL Server Compact jest w rzeczywistości lepszą, szybszą i bardziej niezawodną alternatywą, która nadal działa z interfejsami programu Access. Podejrzewam, że SQLite jest znacznie trwalszy niż baza danych Access, nawet jeśli technicznie jest to udostępnione rozwiązanie plików.
Robert Harvey
@RobertHarvey - Mamy wymagania biznesowe, w których MS Access od 10 lat jest wystarczająco dobrym (tj. Lepszym niż Excel) rozwiązaniem. Kiedy zostaje zawarta ważna umowa, musimy mieć coś gotowego do działania. Zaawansowani użytkownicy z umiejętnościami dostępu są znacznie łatwiejsi do znalezienia i wykorzystania. Funkcjonalność musi być dostępna do określonej daty, ale mamy szczęście, że skalowalność, wydajność, wzrost danych i bezpieczeństwo nigdy nie były czynnikiem. Ulepszanie dostępu, teraz jest inna historia.
JeffO
Nie zrozum mnie źle; Myślę, że Access jest świetny. Ale SQL Server Compact byłby moim minimalnym wymaganiem backendowym dla wszystkich nowych aplikacji Access, w których użytkownicy współużytkują dane.
Robert Harvey
@RobertHarvey - Będę musiał to sprawdzić. Dzięki
JeffO
12

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”).

Jalayn
źródło
Patrzyłem na CE, ale jakoś wydaje się, że SQLite jest lepszy / szybszy / łatwiejszy. Nie wiem na pewno, nie użyłem / przetestowałem CE na tyle, aby się upewnić.
5

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.

Michael Borgwardt
źródło
Rozumiem i zgadzam się. Ale w moim zawodzie tak naprawdę nie mam klientów, którzy używają naszych produktów (standardowych i niestandardowych, głównie związanych z ERP) z więcej niż 10 osobami. Średnio jest to nawet 5-6 użytkowników. Przeredaguję moje pytanie.
4
@Markus V: Pytanie brzmi: jeśli klient bardzo się urósł i stwierdzi, że aplikacja, którą zbudowałeś, staje się niemożliwie powolna w użyciu, i mówisz im, że powodem jest to, że DBMS nie może obsłużyć tylu użytkowników, a oni pytają „ dlaczego nie użyłeś lepszego DBMS ”, jak myślisz, skąd odpowiedź„ trudno jest zainstalować ”? Mogę powiedzieć, jaka byłaby moja reakcja: pomyślałbym „to amator. Muszę znaleźć kogoś innego, kto mógłby napisać moje oprogramowanie”.
Michael Borgwardt,
Masz rację. Nie sądzę, że miałeś na myśli to w ten sposób, ale zapewniam cię, że nie jestem amatorem. Zdecydowanie użyję „prawdziwych” systemów DBMS, jeśli sytuacja o to poprosi. Nasze produkty są licencjonowane dla wielu użytkowników. Programowałbym za pomocą SQLite tylko wtedy, gdybym wiedział, że liczba użytkowników jest stosunkowo niewielka (<10-15). Jeśli klient przekroczy limit, który w naszej bazie klientów nie nastąpi wkrótce, zawsze możemy względnie szybko / prosto przekonwertować go na inną bazę danych. To nie jest nauka o rakietach;). Na podstawie twoich uwag sformułowałem pytanie, aby było bardziej jasne.
Użytkownik, który płacze z powodu przerastania aplikacji, został prawdopodobnie poinformowany o ograniczeniach użytkownika, ale wybrał tańszą drogę. Wszystko jest w porządku z początkową konfiguracją, ale czy będą zadowoleni, gdy będziesz musiał naliczyć im kolejną opłatę za instalację na nowym serwerze, kiedy mogliby po prostu skopiować plik?
JeffO
1
@Jeff O: Chyba źle zrozumiałeś moje intencje. Ja nie wybiera SQLite bo to nic nie kosztuje, tani i / lub łatwe do zainstalowania. Wybrałbym to tylko dlatego, że jest mały, szybki i przyjazny dla zasobów. Jest to głównie ze względów praktycznych / technicznych. 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 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, robi to MSSQL.
4

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

Homde
źródło
2
Masz rację. MS-SQL Express jest produktem wysokiej jakości. Po prostu uważam, że jest trochę rozdęty i zużywa zbyt wiele zasobów. W dzisiejszych czasach komputery / serwery nie stanowią problemu. Jestem po prostu oldschoolową osobą, która wciąż uważa, że ​​mocniejszy sprzęt nie oznacza, że ​​powinienem zaniedbać / zmarnować zasoby, jeśli mogę tego uniknąć. Mniej to lepiej ...;).
2
baza danych z silnikami DB może zoptymalizować dostęp poprzez buforowanie pamięci zamiast odczytu / zapisu z dysków. Ale nie jestem pewny co do wydajności procesowej bazy danych, takiej jak SQL Lite
sarat
1
@sarat: Afaik SQLite intensywnie korzysta z buforów pamięci.
2

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 :-)

Maniak
źródło
1
Szanuję twoją opinię. Jestem tylko praktycznym mężczyzną. Wybierając narzędzie, wybieram je, ponieważ uważam, że jest to najbardziej realistyczna / praktyczna decyzja. SQLite mnie nie fascynuje, ale podziwiam sposób, w jaki udało im się tak dużo w tak małym, wydajnym i szybkim pakiecie. Jak wspomniałem w moim pytaniu: jeśli MS-SQL jest lepszym narzędziem do określonego zadania, po prostu wybrałbym to. Ale, jak wyjaśniłem, przy wielu okazjach naprawdę wierzę, że SQLite po prostu dobrze pasuje.
Ta ilość wykorzystania danych jest duża, jeśli.
JeffO
@Jeff O: Racja. Wybrałbym SQLite tylko wtedy, gdy liczba użytkowników jest stosunkowo niska (<10-15), a także całkowita ilość danych nie jest wysoka. Z naszego doświadczenia wynika, że ​​całkowity rozmiar bazy danych wynosi często 300–400 MB i prawie nigdy> 1 GB.
1

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ć.

quant_dev
źródło