"SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world."
Niemand hat gesagt, dass man ein DBMS nicht in Form einer Bibliothek implementieren könnte. Aus Wikipedia:
Ein DBS besteht aus zwei Teilen: der Verwaltungssoftware, genannt Datenbankmanagementsystem (DBMS) und der Menge der zu verwaltenden Daten, der eigentlichen Datenbank (DB). Die Verwaltungssoftware organisiert intern die strukturierte Speicherung der Daten und kontrolliert alle lesenden und schreibenden Zugriffe auf die Datenbank.
Da ist lediglich von Software die Rede, und eine Bibliothek ist natürlich Software.
Jetzt ist mir klar warum die macher von OO nicht squlite sondern hsqldb als interne DB gewählt haben. Solch trivialen Features wie Fremdschlüssel nicht abzubilden - da fragt man sich nach welchen Kriterien überhaupt das Prädikat 'SQL'-Datenbank beansprucht wird. Fremdschlüssel werden schon bei der 2 Stunde SQL-Einführung behandelt und benötigt ...
Ach ja .. sie werden nur für das Thema 'relationale Datenbank' benötigt - sqlite war also eine nicht-relationale Datenbank mit SQL-Abfragesyntax für den kläglichen Rest?
Von Unverantwortlicher Provokateur am Fr, 23. Juli 2010 um 13:46 #
In meiner Erfahrung sind Fremdschlüssel bzw. deren strikte Überwachung und Erzwingung durch die Datenbankengine vor allem dann sinnvoll, wenn eine Datenbank von verschiedenen Anwendungen benutzt wird, und man nicht allen Anwendungen gleichermaßen vertrauen kann, solche Sachen zu prüfen. Bei SQLite hast Du in der Regel nur eine einzelne Anwendung, die die Datenbank verwendet, und in der Regel auch keine schrecklich komplizierten Datenbank-Schemata, so dass es im Regelfall vertretbar ist, solche Sachen in der Anwendung zu prüfen. Außerdem kann man - lt. SQLite-Doku - Trigger einsetzen, um solche Dinge zu prüfen. Und, ja, ab einer gewissen Komplexität ist man dann doch mit einer ausgewachsenen Lösung wie PostgreSQL besser beraten. SQLite will nicht die eine Lösung für alle Probleme sein. Aber in der Nische, die SQLite ausfüllt, funktioniert es in meiner Erfahrung sehr gut. Und HSQL hat meines Wissens - ich lasse mich da aber gern eines Besseren belehren - das Problem, dass es nur von Java aus funktioniert, während SQLite von vielen Sprachen aus nutzbar ist (und z.B. seit Python 2.5 Teil der Standardbibliothek ist).
Ich glaube wir reden von verschiedenen Dingen. Ein Fremdschlüssel ist ein Feld in einer Relation A über die eine andere Tabelle B mit der ersteren verknüpft wird. Der Fremdschlüssel in A muss der Primärschlüssel in B sein. Erklärst du mir bitte wie ich 2 Tabellen verknüpfen soll bei der ich keinen Fremdschlüssel in A haben kann?
Sieh dir mal http://de.wikipedia.org/wiki/Schlüssel_(Datenbank) hier das Beispiel an
Ich weiß schon, was Fremdschlüssel sind, keine Sorge. ;-) Du kannst auch mit SQLite zwei Tabellen so benutzen, dass Spalte user_id in Tabelle kommentar auf die Spalte id in der Tabelle verweist, ohne dass das DBMS zwingend prüft, ob auch jede user_id auch einer existierenden id in der user-Tabelle entspricht. Dann musst Du halt in Deiner Anwendung Sorge dafür tragen, dass Du nur gültige Werte in die user_id einträgst.
Der Unterschied in der Frage zwischen SQLite und z.B. PostgreSQL, ist dass PostgreSQL wie gesagt prüft, ob jede user_id einer existenten id in der user-Tabelle entspricht und ein INSERT/UPDATE auf kommentar nicht zulässt, wenn das nicht der Fall ist. Und in den meisten Fällen, in denen ich SQLite einsetze, kann ich diese Prüfung mit vertretbarem Aufwand auch in meiner Anwendung ausführen. Als anderes Beispiel sei auf MyISAM-Tabellen in MySQL verwiesen, die auch keine Foreign Keys unterstützen, aber für einfache Web-Anwendungen sehr populär waren (ist schon länger her, dass ich mit MySQL was gemacht habe, also wahrscheinlich nicht mehr aktuell).
Versteh mich bitte nicht falsch - die Fälle, in denen ich SQLite einsetze, sind sehr simpel, die Datenbank hat dann höchstens zwei oder drei Tabellen, und sobald es etwas komplexer wird, oder aber mehrere Anwendungen auf einen gemeinsamen Datenbestand zugreifen müssen, ist für mich PostgreSQL das DBMS der Wahl. Auch wenn z.B. mehrere Instanzen einer Anwendung parallel auf eine Datenbank zugreifen, ist PostgreSQL von der Performance her einfach besser. Und wenn ich z.B. eine Auftragsverwaltung schreiben müsste, bei der es inakzeptabel wäre, dass da auf einmal Aufträge ohne dazugehörigen Kunden herum liegen, dann würde ich mit Sicherheit kein SQLite einsetzen.
Dass SQLite sich eher als Nischenlösung versteht, wird für mich auch am Typensystem deutlich, das a) nur vier Typen kennt (Integer, Real, Text und Blob) und b) in den meisten Fällen erlaubt, beliebige Typen in beliebige Spalten einer Tabelle zu speichern. Was für viele einfache Anwendungsfälle völlig in Ordnung ist - wiederum: wenn nur eine einzelne Anwendung auf die Datenbank zugreift, kann ich in der Anwendung sicherstellen, dass ich keinen Unsinn in die Datenbank schreibe. Sobald es mehrere Anwendungen werden, oder ich absolut sicher gehen will, dass in einer Spalte nur gültige IPv6-Adressen oder eMail-Adressen stehen, ist dann wieder ein ausgewachsenes RDBMS fällig.
In den Fällen, in denen ich SQLite einsetze, würde ich sogar sagen, verwende ich das gar nicht unbedingt als Alternative zu einem ausgewachsenenen RDBMS, sondern als Alternative zu einem selbstgestrickten Dateiformat, XML (*schauder*) oder solchen Geschichten. In den Fällen würde ich vor einem Client-Server-basierten RDBMS zurück schrecken, weil dann auf einmal der Aufwand hinzu kommt, den Server zu administrieren.
[Ich erwähne des Öfteren PostgreSQL, weil das mein ausgewachsenes RDBMS der Wahl ist; wer diese Meinung nicht teil, setze da bitte Oracle/DB2/MySQL/Firebird/ ein.]
Also, um es kurz zu sagen, ich verstehe schon, worauf Du hinaus willst und wieso Dir der Gedanke an ein RDBMS, das keine Fremdschlüssel versteht, Bauchschmerzen bereitet; aber es gibt halt Szenarien, in denen das kein echtes Problem ist, und in denen hat SQLite seine berechtigte Rolle.
"Die Entwickler des ressourcenschonenden Datenbankmanagementsystems (DBMS) SQLite haben eine neue Version veröffentlicht."
Habe ich da was verpasst, seit wann ist SQLite ein DBMS?
Was soll SQLite denn sonst sein??
Auf der Seite steht dazu:
"SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world."
Was verstehst du an "SQL database engine" nicht?
Offentsichtlich scheint dir der Unterschied zwischen Bibliothek und Programm nicht ganz klar zu sein.
Niemand hat gesagt, dass man ein DBMS nicht in Form einer Bibliothek implementieren könnte.
Aus Wikipedia:
Da ist lediglich von Software die Rede, und eine Bibliothek ist natürlich Software.
Tja, und eine "SQL database engine" ist eben ein DBMS.
Jetzt ist mir klar warum die macher von OO nicht squlite sondern hsqldb als interne DB gewählt haben. Solch trivialen Features wie Fremdschlüssel nicht abzubilden - da fragt man sich nach welchen Kriterien überhaupt das Prädikat 'SQL'-Datenbank beansprucht wird. Fremdschlüssel werden schon bei der 2 Stunde SQL-Einführung behandelt und benötigt ...
Ach ja .. sie werden nur für das Thema 'relationale Datenbank' benötigt - sqlite war also eine nicht-relationale Datenbank mit SQL-Abfragesyntax für den kläglichen Rest?
Wurzel
In meiner Erfahrung sind Fremdschlüssel bzw. deren strikte Überwachung und Erzwingung durch die Datenbankengine vor allem dann sinnvoll, wenn eine Datenbank von verschiedenen Anwendungen benutzt wird, und man nicht allen Anwendungen gleichermaßen vertrauen kann, solche Sachen zu prüfen.
Bei SQLite hast Du in der Regel nur eine einzelne Anwendung, die die Datenbank verwendet, und in der Regel auch keine schrecklich komplizierten Datenbank-Schemata, so dass es im Regelfall vertretbar ist, solche Sachen in der Anwendung zu prüfen.
Außerdem kann man - lt. SQLite-Doku - Trigger einsetzen, um solche Dinge zu prüfen.
Und, ja, ab einer gewissen Komplexität ist man dann doch mit einer ausgewachsenen Lösung wie PostgreSQL besser beraten. SQLite will nicht die eine Lösung für alle Probleme sein. Aber in der Nische, die SQLite ausfüllt, funktioniert es in meiner Erfahrung sehr gut.
Und HSQL hat meines Wissens - ich lasse mich da aber gern eines Besseren belehren - das Problem, dass es nur von Java aus funktioniert, während SQLite von vielen Sprachen aus nutzbar ist (und z.B. seit Python 2.5 Teil der Standardbibliothek ist).
Cheers!
Ich glaube wir reden von verschiedenen Dingen. Ein Fremdschlüssel ist ein Feld in einer Relation A über die eine andere Tabelle B mit der ersteren verknüpft wird. Der Fremdschlüssel in A muss der Primärschlüssel in B sein. Erklärst du mir bitte wie ich 2 Tabellen verknüpfen soll bei der ich keinen Fremdschlüssel in A haben kann?
Sieh dir mal
http://de.wikipedia.org/wiki/Schlüssel_(Datenbank)
hier das Beispiel an
mfg
Wurzel
Ich weiß schon, was Fremdschlüssel sind, keine Sorge. ;-)
Du kannst auch mit SQLite zwei Tabellen so benutzen, dass Spalte user_id in Tabelle kommentar auf die Spalte id in der Tabelle verweist, ohne dass das DBMS zwingend prüft, ob auch jede user_id auch einer existierenden id in der user-Tabelle entspricht. Dann musst Du halt in Deiner Anwendung Sorge dafür tragen, dass Du nur gültige Werte in die user_id einträgst.
Der Unterschied in der Frage zwischen SQLite und z.B. PostgreSQL, ist dass PostgreSQL wie gesagt prüft, ob jede user_id einer existenten id in der user-Tabelle entspricht und ein INSERT/UPDATE auf kommentar nicht zulässt, wenn das nicht der Fall ist. Und in den meisten Fällen, in denen ich SQLite einsetze, kann ich diese Prüfung mit vertretbarem Aufwand auch in meiner Anwendung ausführen.
Als anderes Beispiel sei auf MyISAM-Tabellen in MySQL verwiesen, die auch keine Foreign Keys unterstützen, aber für einfache Web-Anwendungen sehr populär waren (ist schon länger her, dass ich mit MySQL was gemacht habe, also wahrscheinlich nicht mehr aktuell).
Versteh mich bitte nicht falsch - die Fälle, in denen ich SQLite einsetze, sind sehr simpel, die Datenbank hat dann höchstens zwei oder drei Tabellen, und sobald es etwas komplexer wird, oder aber mehrere Anwendungen auf einen gemeinsamen Datenbestand zugreifen müssen, ist für mich PostgreSQL das DBMS der Wahl. Auch wenn z.B. mehrere Instanzen einer Anwendung parallel auf eine Datenbank zugreifen, ist PostgreSQL von der Performance her einfach besser.
Und wenn ich z.B. eine Auftragsverwaltung schreiben müsste, bei der es inakzeptabel wäre, dass da auf einmal Aufträge ohne dazugehörigen Kunden herum liegen, dann würde ich mit Sicherheit kein SQLite einsetzen.
Dass SQLite sich eher als Nischenlösung versteht, wird für mich auch am Typensystem deutlich, das a) nur vier Typen kennt (Integer, Real, Text und Blob) und b) in den meisten Fällen erlaubt, beliebige Typen in beliebige Spalten einer Tabelle zu speichern. Was für viele einfache Anwendungsfälle völlig in Ordnung ist - wiederum: wenn nur eine einzelne Anwendung auf die Datenbank zugreift, kann ich in der Anwendung sicherstellen, dass ich keinen Unsinn in die Datenbank schreibe. Sobald es mehrere Anwendungen werden, oder ich absolut sicher gehen will, dass in einer Spalte nur gültige IPv6-Adressen oder eMail-Adressen stehen, ist dann wieder ein ausgewachsenes RDBMS fällig.
In den Fällen, in denen ich SQLite einsetze, würde ich sogar sagen, verwende ich das gar nicht unbedingt als Alternative zu einem ausgewachsenenen RDBMS, sondern als Alternative zu einem selbstgestrickten Dateiformat, XML (*schauder*) oder solchen Geschichten. In den Fällen würde ich vor einem Client-Server-basierten RDBMS zurück schrecken, weil dann auf einmal der Aufwand hinzu kommt, den Server zu administrieren.
[Ich erwähne des Öfteren PostgreSQL, weil das mein ausgewachsenes RDBMS der Wahl ist; wer diese Meinung nicht teil, setze da bitte Oracle/DB2/MySQL/Firebird/ ein.]
Also, um es kurz zu sagen, ich verstehe schon, worauf Du hinaus willst und wieso Dir der Gedanke an ein RDBMS, das keine Fremdschlüssel versteht, Bauchschmerzen bereitet; aber es gibt halt Szenarien, in denen das kein echtes Problem ist, und in denen hat SQLite seine berechtigte Rolle.
Cheers!
WoW, da hat sich jemand Muehe gegeben.
er muss uns aber noch verraten, wie er das macht, wenn er pgsql nimmt (mit FS) und zu einem Auftrag der Kunde noch nicht bekannt ist.