A
wie unix-tom weiter oben bereits angesprochen hat ist SQLite ein projekt welches einem jeden zeigt, was hinter einem dbms steckt.
SQLite ist allerdings etwas anderes als z.b. MySQL o.ä. DBMS
es gibt einige technische unterschiede, die hier alleine aufzuzählen den rahmen sprengen würde. deshalb fasse ich mich nur kurz:
sqlite ist ein lokales dbms. sqlite programmiertechnisch eine bibliothek - eine einzige dll. die daten werden in seperaten dateien gespeichert, die vom user ausgewählt werden.
zwar gibt es auch von systemen wie mysql embeded gegenstücke, die ähnlich zu bedienen sind, allerdings wiederrum lizenspflichtig sind. und meistens nutzt man bei solchen systemen die hauptanwendung, die wäre: ein server (lauffähig als dienst/daemon) an den man sich über das netzwerk einloggen kann. man hat praktisch eine schnittstelle in seinem programm (z.b. mysql++) die einen connect zu einem host erlaubt.
wer eine datenbank nur von einem client aus nutzt, oder die datenbank schnell und unkompliziert transportabel halten möchte bekommt von mir den tipp sqlite eine chance zu geben. wer allerdings zu verschiedenen datenbanken und/oder zu datenbanken in einem netzwerk connecten möchte, ist mit mysql und co. besser beraten.
sqlite ist meiner meinung nach perfekt an den stand alone einsatz angepasst. diese vorteile sind gleichzeitig nachteile grosser dbms wie mysql. umgekehrt ist auch das verhältnis der nachteile.
sqlite trägt nicht so viel codelast und reduziert sich auch auf das nötigste. es bietet zwei abfrage möglichkeiten. mit und ohne callbackfunktionen. wobei man sich jetzt darüber streiten kann ob man ein abfrageverfahren zu gunsten der performance kürzen könnte. ein weiterer +. wäre imho die möglichkeit bestimmte queries zu compilieren. damit würden sich die zeiten von statische abfragen aus grossen tabellen drastisch reduzieren. zumindest von der dokumentation dieser exp funktion war ich bis jetzt begeistert, da man gerade in kleineren lokalen anwendungen viele vorteile davon erwarten könnte.
sicherlich stösst sqlite irgendwann an die grenzen, wobei systeme wie mysql dort gerade erst mit ihren vorteilen anfangen können. jedoch sollte man bedenken, das licht schatten verursacht. mysql oder diverse microsoft db lösungen über odbc sind deutlich langsamer, wenn es darum geht im offline bereich grosse aber unkomplizierte db zu verwalten. allerdings bietet sqlite keine netzwerkunterstützung und ist somit nur eine freude, solange man die datenbanken auf einem rechner hat.
an sqlite wird noch weitergearbeitet und ich hoffe ich werde mich auch selbst irgendwann im stande sehen selbst beiträge zu diesem tollen projekt zu machen. es gibt dort nämlich kleinigkeiten, die bei manch anderen systemen bereits besser gelöst worden sind. z.b. multiuser funktionen. mehrere clients an der selben datenbank. zwar bietet sqlite bereits schon die grundlage für die multiuser funktion, aber es fehlt die nötige api, die dem user die arbeit abnimmt. mysql z.b. kümmert sich selbst darum, ob ein anderer thread bereits auf die datenbank zugreift, und wenn ja, wartet mysql mit der ausführung des queries. bei sqlite muss der benutzer - wenn weiss, dass seine mt anwendung möglicherweise simultan zugreifen wird - versuchen seine queries in einer schleife abzusetzen und als bedingung die prüfung nach einem lock der db file anführen. ausserdem fehlt imho ein lock auf einzelne tabellen und einzelne rows. hier gibt es glaube ich noch nicht einmal vorbereitungen.
falls irgendjemand mehr zum thema sqlite erfahren möchte, sollte er/sie sich meinen beitrag zum sqlite projekt anschauen und bei interesse vielleicht auch kontakt zu mir aufnehmen.
