Al primo accesso il tempo apparirà più velocemente in SQLite
Il tempo di accesso per SQLite apparirà più veloce in prima istanza, ma questo è con un numero limitato di utenti online. SQLite utilizza un algoritmo di accesso molto semplicistico, è veloce ma non gestisce la concorrenza.
Man mano che il database inizia a crescere e la quantità di accesso simultaneo, inizierà a risentirne. Il modo in cui i server gestiscono più richieste è completamente diverso e molto più complesso e ottimizzato per un'elevata concorrenza. Ad esempio, SQLite bloccherà l'intera tabella se è in corso un aggiornamento e accoderà gli ordini.
Gli RDBMS fanno molto lavoro extra che li rende più scalabili
MySQL ad esempio, anche con un singolo utente creerà una CODA di accesso, bloccherà parzialmente le tabelle invece di consentire solo esecuzioni per singolo utente per volta e altre attività piuttosto complesse per assicurarsi che il database sia ancora accessibile per qualsiasi altro accesso simultaneo.
Ciò renderà più lenta la connessione di un singolo utente, ma ripaga in futuro, quando centinaia di utenti saranno online e, in questo caso, la semplice procedura "BLOCCARE L'INTERA TABELLA ED ESEGUIRE UNA SINGOLA QUERY OGNI VOLTA" di SQLite monopolizzerà il server .
SQLite è fatto per semplicità e applicazioni di database indipendenti.
Se prevedi di avere 10 accessi simultanei in scrittura al database alla volta, SQLite potrebbe funzionare bene, ma non vorrai un'applicazione da 100 utenti che scriva e legga costantemente i dati nel database utilizzando SQLite. Non è stato progettato per uno scenario del genere e scaccerà le risorse.
Considerando il tuo scenario TeamSpeak, è probabile che tu sia d'accordo con SQLite, anche per alcune attività va bene, alcuni siti Web necessitano di database che verranno letti in sola lettura a meno che non vengano aggiunti nuovi contenuti.
Per questo tipo di usi SQLite è una soluzione economica, facile da implementare, autonoma e perfetta che porterà a termine il lavoro.
