Ist SQLite nicht ein bisschen unterschätzt? [geschlossen]

Bevor ich die Frage stelle, möchte ich zunächst meine Gedanken zu SQLite beschreiben.

Ich mag Tools, die klein, schnell und vor allem nur die wirklich notwendige Funktionalität haben. Deshalb mag ich SQLite und MS-SQL ein bisschen weniger.

Zum Beispiel: MS-SQL verfügt möglicherweise über viel mehr Funktionen, Skalierbarkeit usw. usw. Die Installation kann jedoch auch schwierig sein, wenn Sie Pech haben. Natürlich sage ich nicht, dass eine schwierige Installation ein Grund ist, sich nicht für eine bestimmte Datenbank zu entscheiden.

Verstehen Sie mich nicht falsch: MS-SQL ist ein Produkt von guter Qualität. Ich bin sehr erfahren mit MS-SQL; Ich verstehe das Produkt sehr gut als Profi. Ich bevorzuge es einfach weniger unter bestimmten Umständen, wo es ist nicht wirklich benötigt wird (= nicht viele Benutzer, <10-15).

Wie viel von der Funktionalität einer Datenbank nutzen Sie wirklich? Nach meiner Erfahrung ist es oft nur das normale SQL (SELECT, INSERT und UPDATE).

Ich mag SQLite. Ist schnell faszinierend. Es ist extrem einfach zu "installieren". Ich denke, SQLite kann mehr, als es behauptet. Warum sollte es nur für Einprozess- / Einzelbenutzeranwendungen verwendet werden? Immerhin: Nicht viele Anwendungen greifen ständig auf eine Datenbank zu.

Beispiel: Stellen Sie sich eine ERP-Anwendung mit beispielsweise 15 Benutzern vor. Warum kann SQLite dafür nicht verwendet werden? Seien wir ehrlich: Nach meiner beruflichen Erfahrung greifen Benutzer dieser Art von Anwendung in den meisten Fällen für etwa 5-10% der Gesamtzeit, in der sie die Anwendung verwenden, auf die Datenbank zu. In den anderen 90-95% beobachten sie nur die Informationen auf dem Bildschirm, geben Daten in ein Raster / Formular ein und wenn sie ihre Eingaben speichern, ist dies nicht mehr als 1 Sekunde der Datenbankzeit. Fe: 1,5 Minuten Eingabezeit gegenüber 1 Sekunde Zeitersparnis.

Wenn die SQLite-Datenbankdatei während der "Zeitersparnis" gesperrt ist, warten andere Benutzer, die auf die Datenbank zugreifen müssen, nur, aber sie bemerken dies nicht, da die Wartezeit sehr gering sein wird (unbemerkt). Im Code muss man sich nur mit der möglichen "ausgelasteten" Zeit der Datenbank auseinandersetzen, um Ausnahmen zu vermeiden, aber das ist nicht schwer zu tun.

Ein Typ, der genauso denken muss wie ich, hat sogar eine Client-Server-Lösung für SQLite entwickelt: SQLitening . Das hat mich mehr überzeugt, dass ich mich nicht selbst täuschen kann.

Natürlich gibt es datenbankintensive Anwendungen, bei denen SQLite nicht passt. Aber wenn ich jetzt darüber nachdenke, sollten viele Mehrbenutzeranwendungen mit SQLite gut funktionieren, wenn sie nicht mehr als 15 Benutzer haben.

Viele unserer Kunden geben nicht viel für Hardware aus, daher stoße ich häufig auf einen einzigen Server, auf dem sich alles befindet (Exchange, SQL (s), Clients usw.) und der fast "außer Atem" ist. Wenn ich ein Produkt liefern könnte, das keine hohen Systemanforderungen hat, wäre mein Kunde glücklich. SQLite fügt kein Gewicht hinzu (zumindest nicht viel), MS-SQL tut dies. Ich würde mich also nicht für SQLite entscheiden, da es kostenlos, günstig oder einfach zu installieren ist. Ich würde es aus praktischen / technischen Gründen wählen.

Zu meiner Information: In meinem Beruf verkaufen wir Produkte (kundenspezifisch und standardmässig, hauptsächlich ERP-bezogen) an Kunden, bei denen durchschnittlich nicht mehr als 5-6 Personen das Produkt verwenden. Es gibt einige Ausnahmen, aber nicht mehr als 10-15 Benutzer.

Die Frage ist: Habe ich Recht, wenn ich denke, dass ich SQLite für eine Mehrbenutzeranwendung wie das von mir beschriebene Beispiel verwenden kann? Gibt es technische Nachteile, die ich kennen sollte? Welche (negativen oder positiven) Erfahrungen werden mir helfen, die richtige Wahl zu treffen?

Update: Bitte sehen Sie dies nicht als negative Beurteilung anderer Datenbanken. Sie sind meist alle feine Produkte. Teile hier nur meine Gedanken mit und bin an deinen Meinungen dazu interessiert.

Es gibt viele Fälle, in denen SQLite reichlich vorhanden ist. Der Benutzer, die Abteilung oder das Unternehmen wachsen selten aus ihm heraus (wir hören nicht so viel davon, weil niemand einen Programmierer anruft, wenn die Anwendung einwandfrei funktioniert.) Sie könnten das gleiche Argument für eine MS Access-Datei (Windows) oder SQL Server Compact Edition (Installation erforderlich). Sie sind alle gut genug für eine lokale Anwendung, da Sie sich nicht so viele Gedanken über die Sicherheit der Datei machen müssen.

In einem Mehrbenutzer-Szenario in einem lokalen Netzwerk wird die Datei in einen freigegebenen Ordner verschoben, auf den alle Benutzer zugreifen müssen - Anrufsicherheit. Einfache Wartung oder Änderungen der Tabellenstruktur, wie z. B. Backups oder das Hinzufügen einer Spalte, verhindern den Zugriff anderer Benutzer. Letzte Nacht hat das Backup nicht funktioniert, weil jemand vergessen hat, die Anwendung zu beenden. Was passiert, wenn Sie mitten am Tag ein Backup erstellen möchten? Alle begründen, dass sie aufgrund der technischen Einschränkungen ihrer Datenbank tagsüber keine Backups benötigen. Zu einem bestimmten Zeitpunkt erfordert die Installation von SQL Server Express / einer anderen Entsprechung auf Ihrem Server einige anfängliche Setup- und Sicherheitskonfigurationen. Dies ist im Vorfeld aufwändiger, erfordert jedoch nur wenig Wartung.

Es besteht immer die Sorge um Skalierbarkeit / Überentwicklung. Selbst wenn die Anzahl der Benutzer oder die Datenmenge noch überschaubar ist, hat immer jemand die Idee, die Live-Daten in einem Intranet oder einer anderen Website / Browser-Oberfläche zu verwenden. Dateidatenbanken weisen Probleme auf. Es ist nur eine Person erforderlich, die über ein VPN auf die Datendatei zugreifen möchte (die App ist auf ihrem Laptop installiert), um das Problem der Skalierung zu lösen. Sie können die App so erstellen, dass nicht verbundene Benutzer bei ihrer Rückkehr eine Synchronisierung durchführen können. Scheint es für gelegentliche Abwesenheitsnutzer einfach nicht wert zu sein.

Ich denke, es ist großartig, wenn Sie eine "interne" Datenbank benötigen. Das heißt, eine Datenbank, mit der Ihre Anwendung / Ihr Code interagiert, die jedoch nicht direkt mit dem Hauptgrund für die Existenz Ihrer Anwendung zusammenhängt. Anstatt riesige In-Memory-Zuordnungen oder Cache-Manager zu verwenden, können Sie auch eine solche Datenbank verwenden. Ich habe ein sehr konkretes Beispiel dafür, da ich es kürzlich in JUnit / DBunit-Testfällen verwendet habe, in denen ich eine Verbindung zu einer Datenbank herstellen, einige Arbeiten ausführen, Daten lesen und am Ende alles löschen musste. Da Sie zum Erstellen der Datenbank nur eine leere Datei erstellen müssen, war dies recht einfach.

Eine andere Verwendung sehe ich: wenn Sie nur einen Benutzer haben. Ja, das ist möglich, denke zum Beispiel an "Firefox" oder "Opera" :-)

Außerdem sind sie auf der SQLite-Website sehr ehrlich und geben Gründe an, wann sie ES NICHT VERWENDEN sollten (siehe Abschnitt "Situationen, in denen ein anderes RDBMS möglicherweise besser funktioniert").

ps: Bezogen auf die Kommentare zu SQL Server Express, ja, es muss "installiert" werden. Und ich hatte einige Probleme damit, es persönlich zu aktualisieren (ich musste einige Registrierungsschlüssel der Vorgängerversion manuell entfernen, um 2008 R2 installieren zu können). Wenn Sie SQLite jedoch mit einer von Microsoft entwickelten Datenbank vergleichen möchten, schauen Sie sich die Sql Server Compact Edition an , die Sie nicht installieren müssen (siehe "Bereitstellung auf der Basis privater Dateien").

Beispiel: Stellen Sie sich eine ERP-Anwendung mit beispielsweise 15 Benutzern vor. Warum kann SQLite dafür nicht verwendet werden?

Sehr wenige Anwendungen haben so wenige Benutzer für immer. Und für alles, was mehr Benutzer und komplexere Datenmanipulationen sieht, kommt die Verwendung von SQLite aus Performancegründen aufgrund des einfachen Sperrmodells "Transaktion zu einem Zeitpunkt schreiben" überhaupt nicht in Frage.

Angenommen, Sie haben 100 Benutzer, die jeweils 60 Sekunden lang ein Formular ausfüllen und dann abschicken. Sie müssen also ungefähr 1,6 Transaktionen pro Sekunde verarbeiten. Das Datenmodell ist komplex und das Speichern eines Formulars umfasst das Lesen und Schreiben in viele große Tabellen, möglicherweise sogar die Kommunikation mit einem anderen System. Jedes "Formular senden" führt zu einer Transaktion, die 2 Sekunden dauert. SQLite kann jedoch keine Transaktionen gleichzeitig verarbeiten. Dies bedeutet, dass nur 0,5 Transaktionen pro Scond verarbeitet werden können. Hoppla.

"Die Installation kann mühsam sein" ist kein guter Grund, sich gegen ein kritisches Stück Infrastruktur zu entscheiden. Außerdem stehen andere DB-Engines zur Auswahl, von denen mindestens zwei (MySQL und Postgres) kostenlos sind und nicht die Parallelitätsbeschränkungen von SQLite aufweisen. Sie sind möglicherweise sogar einfacher zu installieren als MS-SQL.

Ich denke, SQLLite eignet sich hervorragend für die Anwendungsentwicklung. Die größte Stärke besteht darin, dass es nicht auf dem Client installiert werden muss.

Unterschätzen Sie jedoch auch SQL Server Express nicht, es handelt sich um eine kostenlose, hervorragende Datenbank mit den meisten Funktionen eines gewöhnlichen SQL-Servers, die nur eine Beschränkung der Datenbankgröße aufweist (die nur schwer zu überschreiten ist), zusammen mit der Fähigkeit, die hervorragenden normalen Tools zu verwenden SQL Server.

Der größte Nachteil ist, dass Sie es installieren müssen. Ich bin mir jedoch ein bisschen unsicher, ob es jetzt ein Ausweg ist

Ich halte SQLite nicht für eine seriöse Datenbank, wenn Sie stündlich mit ein paar GB Daten zu tun haben. Es wird schmerzhaft langsam und beeinträchtigt die Leistung der gesamten Anwendung. Sorry, aber ich stimme deiner Faszination für SQLite nicht zu :-)

Das Problem bei Datenbanken ist, dass sie dazu neigen, immer mehr Daten anzusammeln. Wenn Sie eine schlanke Datenbank auswählen, besteht das Risiko, dass Ihr Tool nicht richtig skaliert wird.