Hallo,
laut FAQ von der Homepage http://sqlite.org/faq.html#q5 ist ein mehrfacher Zugriff auf eine SQLite-DB zwar nicht möglich aber man kann bei Beachtung des verwendeten Dateisystems mittels Lockstatus wohl den schreibenden Zugriff regeln.
Ich wollte eure Einschätzung mal dazu hören, da ich gerade so etwas vorhabe.
Es handelt sich dabei um ein Noteneingabe-Programm, bei dem mehrere Kollegen durchaus gleichzeitig ein eigenes Programm geöffnet haben, der schreibende Zugriff auf die DB aber nur am Ende der Eingabe in die Tabelle erfolgt. Ich schätze, dass zwischen zwei Schreibvorgängen durchaus ein paar Minuten liegen können, also nicht alle 1-2 Sekunden auf die Datenbank schreibend zugegriffen wird.
Alle anderen Zugriffe sind nur lesend.
Hat jemand damit schon Erfahrung oder ist es einfach das falsche Werkzeug dafür und ich sollte besser ein Client/Server-DBMS a la MySQL verwenden?
Vielen Dank für eure Einschätzungen!
Gruß EmaNymton
kurze Einschätzung bzgl. SQLite und Multiuser-Anwendung
Hallo,
ich persönlich habe die Erfahrung gemacht, dass 'kann vorkommen, ist aber sehr unwahrscheinlich' einem früher oder später das Genick bricht
Du sagst ein gleichzeitiger Schreibzugriff 'kann vorkommen' aber es wird so selten geschrieben da ist das 'sehr unwahrscheinlich'.
Ich finde das klingt nach einer super Aufgabe für PostgreSQL oder mySQL
Gruß
sparrow
ich persönlich habe die Erfahrung gemacht, dass 'kann vorkommen, ist aber sehr unwahrscheinlich' einem früher oder später das Genick bricht
Du sagst ein gleichzeitiger Schreibzugriff 'kann vorkommen' aber es wird so selten geschrieben da ist das 'sehr unwahrscheinlich'.
Ich finde das klingt nach einer super Aufgabe für PostgreSQL oder mySQL
Gruß
sparrow
Danke für deine Einschätzung.
Ich habe aber nirgendwo geschrieben, dass ich es für unwahrscheinlich halte, dass gleichzeitiger Schreibzugriff vorkommt. Ich gehe sogar davon aus, dass es vorkommt, ansonsten würde ich mir ja keine Gedanken darüber machen.
Meine Frage war eher, ob der zeitliche Aufwand, den ich in das Aufsetzen und Absichern eines SQL-Servers investiere, größer ist, als der Aufwand, das gleiche bei einer Programmierung mit Hilfe einer SQLite-DB hinzubekommen.
Mein Problem ist halt, dass mir in dem Bereich die Erfahrung fehlt, um die Machbarkeit abschätzen zu können. Hier wäre ich für Erfahrungen/Meinungen anderer dankbar.
Gruß EmaNymton
Ich habe aber nirgendwo geschrieben, dass ich es für unwahrscheinlich halte, dass gleichzeitiger Schreibzugriff vorkommt. Ich gehe sogar davon aus, dass es vorkommt, ansonsten würde ich mir ja keine Gedanken darüber machen.
Meine Frage war eher, ob der zeitliche Aufwand, den ich in das Aufsetzen und Absichern eines SQL-Servers investiere, größer ist, als der Aufwand, das gleiche bei einer Programmierung mit Hilfe einer SQLite-DB hinzubekommen.
Mein Problem ist halt, dass mir in dem Bereich die Erfahrung fehlt, um die Machbarkeit abschätzen zu können. Hier wäre ich für Erfahrungen/Meinungen anderer dankbar.
Gruß EmaNymton
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das Problem sind meiner Meinung nach eher nicht die gleichzeitigen Writes, denn das sind wenige und da kann man Locks verwenden. Wo ich eher das Problem sehe ist die Desynchronisation. Nehmen wir an User 1 liest was aus der Datenbank, User 2 danach auch. Nun editiert User 1 die Daten auf eine Weise, User 2 ebenfalls. Jetzt schreibt User 1 in die Datenbank, und User 2 kurz danach auch. Oha, User 2 hat die Daten von User 1 überschrieben, Das ist eher ein Problem das man angehen sollte. Seltene Schreibzugriffe mittels Locks absichern sollte hingegen kein Problem sein (man muss das halt nur auch machen und nicht hoffen das sich das magisch von selbst löst).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Danke für die neue Sichtweise. Das von dir beschriebene Problem sollte aber in meinem Fall nicht auftreten, da jeder User "eigene Daten" erhält, User 1 kann also nicht auf Daten von User 2 zugreifen und sie somit überschreiben. Soweit ich dann nicht die ganze Tabelle update, sondern nur den jeweiligen Datensatz, sollte es doch dann mit dem Überschreiben kein Problem sein, oder?
Um es konkreter zu machen: Die DB besteht aus den Tabellen Schueler, Kursen, Lehrer und den Beziehungstabellen. Startet ein Lehrer das Programm und identifiziert sich über sein Kürzel so bekommt er nur die Kurse zu sehen, die er unterrichtet. Dort kann er dann seine Noten/Fehlstunden eintragen bei den Schülern, die den Kurs belegen. Bitte berichtigt mich, wenn ich mit meiner obigen Annahme falsch liege.
Gruß EmaNymton
Um es konkreter zu machen: Die DB besteht aus den Tabellen Schueler, Kursen, Lehrer und den Beziehungstabellen. Startet ein Lehrer das Programm und identifiziert sich über sein Kürzel so bekommt er nur die Kurse zu sehen, die er unterrichtet. Dort kann er dann seine Noten/Fehlstunden eintragen bei den Schülern, die den Kurs belegen. Bitte berichtigt mich, wenn ich mit meiner obigen Annahme falsch liege.
Gruß EmaNymton
-
noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
wenn du "konkurrierende" Lese- / Schreibzugriffe aufgrund des Design ausschließen kannst, dann sehe ich jetzt kein Problem dabei. Vorausgesetzt, du hast du Locks gesetzt.
Andere Programme wie z.B. Trac nutzen ja per Default SQLite - und es funktioniert, "trotz" Multiuser etc.
Ansonsten ist aber das Aufsetzen eines DB-Servers wie MySQL oder PostgreSQL auch kein Hexenwerk. Sofern du eine Linuxdistribution nutzt und der DB-Server auf "localhost" läuft ist in der Regel nach der Installation aus den Paketquellen ootb. Ggf. muss man halt noch die Nutzer in der DB anlegen (was bei vielen Nutzern dann doch evtl. in Arbeit ausartet ).
Gruß, noisefloor
wenn du "konkurrierende" Lese- / Schreibzugriffe aufgrund des Design ausschließen kannst, dann sehe ich jetzt kein Problem dabei. Vorausgesetzt, du hast du Locks gesetzt.
Andere Programme wie z.B. Trac nutzen ja per Default SQLite - und es funktioniert, "trotz" Multiuser etc.
Ansonsten ist aber das Aufsetzen eines DB-Servers wie MySQL oder PostgreSQL auch kein Hexenwerk. Sofern du eine Linuxdistribution nutzt und der DB-Server auf "localhost" läuft ist in der Regel nach der Installation aus den Paketquellen ootb. Ggf. muss man halt noch die Nutzer in der DB anlegen (was bei vielen Nutzern dann doch evtl. in Arbeit ausartet
).Gruß, noisefloor
burli hat geschrieben:Gibt es einen bestimmten Grund, warum du SQLite und nicht gleich MySQL oder Postgresql verwenden willst?
Das ist u.a. einer der Gründe. Ein anderer ist, dass die Eingabe und Auswertung in zwei physikalisch getrennten Netzwerken erfolgt/erfolgen muss, so dass mir eine Datei-basierte Lösung lieber wäre, da die Daten einfach über USB-Stick transportiert werden können. Auch ist mir der Sicherheitsgedanke hier wichtig, da ich sonst für ca. 100 Kollegen ein Passwort vergeben müsste (ich weiß, dass man das auch automatisieren kann, ist aber auch wieder zusätzlicher Aufwand).noisefloor hat geschrieben: Ggf. muss man halt noch die Nutzer in der DB anlegen (was bei vielen Nutzern dann doch evtl. in Arbeit ausartet
Ich werde es jetzt erstmal mit SQLite versuchen und testen. Im Zweifelsfall sollte man ja relativ schnell auf MySQL umschwenken können, da die SQL-Statements ja identisch sind und "nur" die Anmeldung am Server implementiert werden muss, oder?
Danke jedenfalls nochmal für eure Ideen/Hinweise.
Gruß EmaNymton
Ich weiß, es ist vermutlich überflüssig, aber ich will mal CouchDB in den Raum stellen. Die Installation und Einrichtung ist, zumindest unter Linux, ein Kinderspiel.
Für den einfachen Betrieb ist eigentlich keinerlei Einrichtung notwendig. Jeder User hat im Prinzip Admin Rechte. Wenn das ein Problem wäre müsste man dann allerdings doch Hand anlegen.
außerdem sprichts du davon, Daten mit dem USB Stick durch die Gegend zu tragen. CouchDB bietet die einfache Möglichkeit, Daten zwischen Rechnern zu synchronisieren
Für den einfachen Betrieb ist eigentlich keinerlei Einrichtung notwendig. Jeder User hat im Prinzip Admin Rechte. Wenn das ein Problem wäre müsste man dann allerdings doch Hand anlegen.
außerdem sprichts du davon, Daten mit dem USB Stick durch die Gegend zu tragen. CouchDB bietet die einfache Möglichkeit, Daten zwischen Rechnern zu synchronisieren
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Dafür kannst Du dort Rechte auch wesentlich fein granularer setzen. Da Du ja augenscheinlich auch schreibenden Zugriff auf die DB erlauben musst, hätte ich bei so vielen Accounts schon Bedenken, das alles über eine User/PW-Kombi abzudecken. Theoretisch kann ja so jeder beliebige User, der den Zugang kennt die DB korrumpieren und zwar komplett. Bei Postgres oder MySQL könntest Du die Rechte restriktiver setzen, afaik bis auf Attributsebene hinab.EmaNymton hat geschrieben: Das ist u.a. einer der Gründe. Ein anderer ist, dass die Eingabe und Auswertung in zwei physikalisch getrennten Netzwerken erfolgt/erfolgen muss, so dass mir eine Datei-basierte Lösung lieber wäre, da die Daten einfach über USB-Stick transportiert werden können. Auch ist mir der Sicherheitsgedanke hier wichtig, da ich sonst für ca. 100 Kollegen ein Passwort vergeben müsste (ich weiß, dass man das auch automatisieren kann, ist aber auch wieder zusätzlicher Aufwand).
Und für die Auswertung kannst Du immer Dumps erstellen - diese per USB zu transportieren und einzuspielen ist auch kein allzu großer Aufwand.
An dieser Stelle könntest Du über den Einsatz eines Abstraktionslayers wie SQLAlchemy nachdenken. Damit solltest Du von Grund auf - von wirklichen Spezialgeschichten abgesehen - DB unabhängig arbeiten können. Für den leichteren Einstige in die ORM-Komponente würde ich auch auf Elixir setzen (der Abstraktionsteil ist identisch zu SQLAlchemy).Ich werde es jetzt erstmal mit SQLite versuchen und testen. Im Zweifelsfall sollte man ja relativ schnell auf MySQL umschwenken können, da die SQL-Statements ja identisch sind und "nur" die Anmeldung am Server implementiert werden muss, oder?
Vor allem könntest Du dann während der Entwicklung auf SQLite setzen und ggf. später leicht auf ein anderes RDBMS switchen.
Einen DB-Server aufzusetzen ist sicherlich Arbeit, aber bei Deinen Anforderungen kann sich das sicherlich lohnen.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Danke für die Hinweise/Stichwörter, vielleicht werde ich doch noch etwas ausführlicher
Es geht wie geschrieben darum, dass die Kollegen eine einfache Möglichkeit haben, am Ende eines Halbjahres die Noten/Fehlstunden einzutragen. Bisher war es so, dass das Verwaltungsprogramm der Schule (gp-untis) für jede Stufe/Klasse Export-Dateien als csv erzeugt und die Kollegen in diese Listen eintragen. Das hat mehrere Nachteile (eine Liste kann immer nur gleichzeitig beschrieben werden, Kollegen können Eingabe-Fehler machen (Punkte statt Noten und umgekehrt, ...), generelle Benutzungsfehler (die ich jetzt hier nicht aufzähle, sonst wird es lang aber amüsant). Wie ihr euch denken könnt, rennt man dann als zuständiger Kollege da immer hinterher und hat nachher das Bedürfnis, es besser zu machen um auf Dauer die Nerven zu schonen
Die Export-Dateien lagen bisher für das Eintragen der Noten in einem geschützten Verzeichnis. Die Kollegen melden sich an der Domäne mit Kürzel und Passwort an und können dann auf dieses Verzeichnis zugreifen. Dort würde ich dann auch die SQLite-DB ablegen, so dass ich mir über die Anmeldung keine Gedanken mehr machen müsste. Die Anmeldung/Identifikation im Programm erfolgt dann ausschließlich über das Kürzel. Die Eintragung an mehreren Rechnern erfolgt aus einem Raum, wo Schüler ohne Aufsicht/Lehrer keinen Zutritt haben.
Zu MySQL:
Es existiert sogar ein MySQL/Linux-Server im pädagogischen Netzwerk, den ich aufgesetzt habe. Der dient aber nur für Programmierübungen für meine Informatikkurse, so dass auch Schüler darauf Zugriff haben. Allerdings wollte ich mir die Absicherung und das Anlegen von allen Benutzern ersparen, da ich mich auf diesem Gebiet eher als Laie sehe und es wäre (für die Schüler vielleicht nicht) kontraproduktiv, wenn die Schüler ihre Noten einsehen und vielleicht sogar verändern könnten.
Ich hoffe, es ist jetzt ein wenig klarer, was ich vorhabe und von welchen Voraussetzungen ich ausgehen kann.
Wenn ich irgendwas übersehen habe oder ihr noch eine geniale Idee habt, immer her damit!
Gruß EmaNymton
Es geht wie geschrieben darum, dass die Kollegen eine einfache Möglichkeit haben, am Ende eines Halbjahres die Noten/Fehlstunden einzutragen. Bisher war es so, dass das Verwaltungsprogramm der Schule (gp-untis) für jede Stufe/Klasse Export-Dateien als csv erzeugt und die Kollegen in diese Listen eintragen. Das hat mehrere Nachteile (eine Liste kann immer nur gleichzeitig beschrieben werden, Kollegen können Eingabe-Fehler machen (Punkte statt Noten und umgekehrt, ...), generelle Benutzungsfehler (die ich jetzt hier nicht aufzähle, sonst wird es lang aber amüsant
). Wie ihr euch denken könnt, rennt man dann als zuständiger Kollege da immer hinterher und hat nachher das Bedürfnis, es besser zu machen um auf Dauer die Nerven zu schonen Die Export-Dateien lagen bisher für das Eintragen der Noten in einem geschützten Verzeichnis. Die Kollegen melden sich an der Domäne mit Kürzel und Passwort an und können dann auf dieses Verzeichnis zugreifen. Dort würde ich dann auch die SQLite-DB ablegen, so dass ich mir über die Anmeldung keine Gedanken mehr machen müsste. Die Anmeldung/Identifikation im Programm erfolgt dann ausschließlich über das Kürzel. Die Eintragung an mehreren Rechnern erfolgt aus einem Raum, wo Schüler ohne Aufsicht/Lehrer keinen Zutritt haben.
Zu MySQL:
Es existiert sogar ein MySQL/Linux-Server im pädagogischen Netzwerk, den ich aufgesetzt habe. Der dient aber nur für Programmierübungen für meine Informatikkurse, so dass auch Schüler darauf Zugriff haben. Allerdings wollte ich mir die Absicherung und das Anlegen von allen Benutzern ersparen, da ich mich auf diesem Gebiet eher als Laie sehe und es wäre (für die Schüler vielleicht nicht
) kontraproduktiv, wenn die Schüler ihre Noten einsehen und vielleicht sogar verändern könnten.Ich hoffe, es ist jetzt ein wenig klarer, was ich vorhabe und von welchen Voraussetzungen ich ausgehen kann.
Wenn ich irgendwas übersehen habe oder ihr noch eine geniale Idee habt, immer her damit!
Gruß EmaNymton
Hallo,
du musst nicht jeden Benutzer einzeln anlegen. Das würdest du doch bei SQLite auch nicht tun, oder?
Eine Alternative: Setze das Programm als Web-Applikation um, dann kannst du sie so umsetzen, dass zwar die Applikation von außen erreichbar ist allerdings die Datenbank selbst nicht.
Wenn du ein Framework wie Django verwendest hast gleich noch eine Abstraktionsschicht zur Datenbank dabei.
Gruß
sparrow
du musst nicht jeden Benutzer einzeln anlegen. Das würdest du doch bei SQLite auch nicht tun, oder?
Eine Alternative: Setze das Programm als Web-Applikation um, dann kannst du sie so umsetzen, dass zwar die Applikation von außen erreichbar ist allerdings die Datenbank selbst nicht.
Wenn du ein Framework wie Django verwendest hast gleich noch eine Abstraktionsschicht zur Datenbank dabei.
Gruß
sparrow