Przy pierwszym dostępie czas pojawi się szybciej w SQLite
Czas dostępu do SQLite pojawi się szybciej w pierwszej instancji, ale dzieje się tak w przypadku niewielkiej liczby użytkowników online. SQLite używa bardzo uproszczonego algorytmu dostępu, jest szybki, ale nie obsługuje współbieżności.
W miarę jak baza danych zaczyna się rozrastać, ucierpi na tym ilość równoczesnego dostępu. Sposób, w jaki serwery obsługują wiele żądań, jest zupełnie inny, bardziej złożony i zoptymalizowany pod kątem wysokiej współbieżności. Na przykład, SQLite zablokuje całą tabelę, jeśli trwa aktualizacja, i zakolejkuje zamówienia.
RDBMS to dużo dodatkowej pracy, która czyni je bardziej skalowalnymi
Na przykład MySQL, nawet z jednym użytkownikiem, utworzy KOLEJKĘ dostępu, częściowo zablokuje tabele zamiast zezwalać na wykonywanie tylko jednego użytkownika na czas i inne dość złożone zadania, aby upewnić się, że baza danych jest nadal dostępna dla każdego innego jednoczesnego dostępu.
Spowoduje to, że połączenie pojedynczego użytkownika będzie wolniejsze, ale opłaca się w przyszłości, gdy setki użytkowników będą online, a w tym przypadku prosta procedura „ZABLOKUJ CAŁĄ TABELĘ I WYKONAJ POJEDYNCZE ZAPYTANIE ZA KAŻDYM RAZEM” spowoduje zatrzymanie serwera .
SQLite został stworzony z myślą o prostocie i samodzielnych aplikacjach bazodanowych.
Jeśli spodziewasz się mieć 10 równoczesnych zapisów w bazie danych na raz, SQLite może działać dobrze, ale nie będziesz potrzebować aplikacji dla 100 użytkowników, która stale zapisuje i odczytuje dane do bazy danych za pomocą SQLite. Nie został zaprojektowany do takiego scenariusza i spowoduje skasowanie zasobów.
Biorąc pod uwagę Twój scenariusz TeamSpeak, prawdopodobnie nie będziesz mieć nic przeciwko SQLite, nawet dla niektórych firm jest to w porządku, niektóre witryny potrzebują baz danych, które będą tylko do odczytu, chyba że podczas dodawania nowej zawartości.
Do tego rodzaju zastosowań SQLite jest tanim, łatwym do wdrożenia, samodzielnym, idealnym rozwiązaniem, które wykona zadanie.
