При първи достъп времето ще се показва по-бързо в SQLite
Времето за достъп за SQLite ще изглежда по-бързо на първа инстанция, но това е с малък брой потребители онлайн. SQLite използва много опростен алгоритъм за достъп, той е бърз, но не обработва едновременност.
Тъй като базата данни започне да расте и количеството на едновременен достъп ще започне да страда. Начинът, по който сървърите обработват множество заявки, е напълно различен и много по-сложен и оптимизиран за висок едновременност. Например, SQLite ще заключи цялата таблица, ако има актуализация, и ще постави поръчките на опашка.
RDBMS прави много допълнителна работа, която ги прави по-мащабируеми
MySQL например, дори с един потребител ще създаде ОПЕШКА за достъп, ще заключи частично таблици, вместо да позволява само изпълнение на един потребител на време и други доста сложни задачи, за да се увери, че базата данни все още е достъпна за всеки друг едновременен достъп.
Това ще направи връзката на един потребител по-бавна, но се изплаща в бъдеще, когато 100 потребители са онлайн и в този случай простата процедура на SQLite „ЗАКЛЮЧАЙТЕ ЦЯЛАТА ТАБЛИЦА И ИЗПЪЛНАЙТЕ ЕДИНИЧНА ЗАПИСВАНЕ ВСЕКИ ПЪТ” ще задържи сървъра .
SQLite е направен за простота и самостоятелни приложения за бази данни.
Ако очаквате да имате 10 едновременни записвания за достъп в базата данни наведнъж, SQLite може да се представи добре, но няма да искате приложение за 100 потребители, което постоянно записва и чете данни в базата данни с помощта на SQLite. Той не е проектиран за такъв сценарий и ще изхвърли ресурси.
Като се има предвид вашия сценарий на TeamSpeak, вероятно ще сте добре със SQLite, дори за някои бизнеси това е добре, някои уебсайтове се нуждаят от бази данни, които ще се четат само, освен ако не добавяте ново съдържание.
За този вид употреби SQLite е евтино, лесно за прилагане, самостоятелно, перфектно решение, което ще свърши работата.
