Hallo zusammen,
ich arbeite momentan an einer Notenverwaltung und hätte eine Frage bzgl. SQLite. Angenommen ich würde die SQLite-Datei auf ein Netzwerklaufwerk legen und von meinem Python-Skript aus darauf zugreifen, dürfte es vermutlich ja keine Probleme geben. Was aber wenn das Python-Skript auf mehrere Rechner im Netzwerk verteilt wird und von dort aus dann auf die SQLite-Datei zugegriffen wird? Ich denke dabei an einen zeitgleichen Zugriff von mehreren Rechnern aus (ist zwar eher unwahrscheinlich, kann aber passieren)? Was kann dann passieren? Wird die Datei vor dem Zugriff durch ein zweites Python-Skript blockiert bis das erste Python-Skript die Datei wieder freigegeben hat?
Viele sonnige Grüße zum Tag der Deutschen Einheit.
snowflake
Zugriff auf SQLite
-
sls
- User
- Beiträge: 480
- Registriert: Mittwoch 13. Mai 2015, 23:52
- Wohnort: Country country = new Zealand();
Prinzipiell können mehrere Connections zu einer SQLite-Datenbank aufgebaut werden und der Lesezugriff parallel erfolgen. SQLite verwendet (ab v3.0.0) "ACID" (Atomic, Consistent, Isolated, and Durable) via pager_module, damit wird sichergestellt, dass nur ein Schreibvorgang zur selben Zeit erfolgt. Quasi ein lock-Mechanismus für die Schreiber.
EDIT: zwei Anmerkungen noch am Rande.
1. Wir haben hier im Forum einen dedizierten Bereich für Datenbankprogrammierung. Im "Allgemeine Fragen"-Bereich hat das eigentlich nichts zu suchen
2. Generell ist die Frage ja völlig legitim, aber für einen ersten Einblick wird in der offiziellen SQLite-Doku genau darauf eingegangen. Die Frage ist ja nicht wirklich speziell oder stellt vor ungeahnte Herausforderungen, es wird hier immer irgendwen geben der noch so triviale Fragen beantwortet. Einen guten Entwickler macht aber u.a. aus, dass man eigenständig recherchiert und bei Problemen die man ohne weiteres nicht Lösen kann andere Leute befragt. Vor allem ist es Probieren und viel Doku lesen.
EDIT: zwei Anmerkungen noch am Rande.
1. Wir haben hier im Forum einen dedizierten Bereich für Datenbankprogrammierung. Im "Allgemeine Fragen"-Bereich hat das eigentlich nichts zu suchen
2. Generell ist die Frage ja völlig legitim, aber für einen ersten Einblick wird in der offiziellen SQLite-Doku genau darauf eingegangen. Die Frage ist ja nicht wirklich speziell oder stellt vor ungeahnte Herausforderungen, es wird hier immer irgendwen geben der noch so triviale Fragen beantwortet. Einen guten Entwickler macht aber u.a. aus, dass man eigenständig recherchiert und bei Problemen die man ohne weiteres nicht Lösen kann andere Leute befragt. Vor allem ist es Probieren und viel Doku lesen.
Zuletzt geändert von sls am Mittwoch 3. Oktober 2018, 10:28, insgesamt 1-mal geändert.
When we say computer, we mean the electronic computer.
SQLite ist für solche Anwendungszwecke m.M.n. nicht gedacht. Der Hauptautor von SQLite beschreibt es selbst manchmal eher als Dateiformat für Programme als als Datenbank im Sinne anderer bekannter RDBMS, die. i.d.R. im Serverbetrieb laufen. Wenn du Mehrbenutzerbetrieb und so etwas möchtest, wäre ein solches RDBMS die bessere Wahl, z.B. Postgresql oder Mariadb.
Zuletzt geändert von nezzcarth am Mittwoch 3. Oktober 2018, 10:33, insgesamt 2-mal geändert.
-
sls
- User
- Beiträge: 480
- Registriert: Mittwoch 13. Mai 2015, 23:52
- Wohnort: Country country = new Zealand();
Guter Einwand, ich glaube SQLite unterstützt nicht mal nativen remote Zugriff. Das DB-File muss also immer irgendwie im selben Netzsegment liegen.nezzcarth hat geschrieben: Mittwoch 3. Oktober 2018, 10:26 Wenn du Mehrbenutzerbetrieb und so etwas möchtest, wäre ein solches RDBMS die bessere Wahl, z.B. Postgresql oder Mariadb.
When we say computer, we mean the electronic computer.
Hallo zusammen,
vielen Dank für die schnellen Antworten. Wenn ich das richtige verstehe, sollte mein Vorhaben kein Problem darstellen, auch wenn es vielleicht nicht optimal ist. Die vorgeschlagenen Datenbanken stellen sicherlich eine bessere Lösung dar, jedoch bin ich nicht in der Lage sowas anzuwenden.
Zu den zwei Anmerkungen von sls:
1. Da hast Du vollkommen recht. Ich habe schlichtweg nicht aufgepasst, in welchen Bereich ich die Frage platziert habe. Das werde ich in Zukunft besser machen.
2. Ich habe in der Dokumentation (https://sqlite.org/transactional.html) von SQLite die Stelle mit "ACID" gelesen. Allerdings kann ich mit meinem Wissensstand in Sachen Python und Datenbanken die gestellte Frage damit nicht beantworten. Deshalb bitte ich wegen der gestellten Frage um Nachsicht.
An dieser Stelle möchte ich einfach mal hervorheben, dass dieses Forum wirklich richtig gut ist und mich für die bisher geleistete Hilfe und Unterstützung herzlich bedanken.
Viele Grüße
snowflake
vielen Dank für die schnellen Antworten. Wenn ich das richtige verstehe, sollte mein Vorhaben kein Problem darstellen, auch wenn es vielleicht nicht optimal ist. Die vorgeschlagenen Datenbanken stellen sicherlich eine bessere Lösung dar, jedoch bin ich nicht in der Lage sowas anzuwenden.
Zu den zwei Anmerkungen von sls:
1. Da hast Du vollkommen recht. Ich habe schlichtweg nicht aufgepasst, in welchen Bereich ich die Frage platziert habe. Das werde ich in Zukunft besser machen.
2. Ich habe in der Dokumentation (https://sqlite.org/transactional.html) von SQLite die Stelle mit "ACID" gelesen. Allerdings kann ich mit meinem Wissensstand in Sachen Python und Datenbanken die gestellte Frage damit nicht beantworten. Deshalb bitte ich wegen der gestellten Frage um Nachsicht.
An dieser Stelle möchte ich einfach mal hervorheben, dass dieses Forum wirklich richtig gut ist und mich für die bisher geleistete Hilfe und Unterstützung herzlich bedanken.
Viele Grüße
snowflake
-
sls
- User
- Beiträge: 480
- Registriert: Mittwoch 13. Mai 2015, 23:52
- Wohnort: Country country = new Zealand();
@snowflake: vielleicht bringt die Antwort in Frage # 5 mehr Licht ins Dunkel: https://sqlite.org/faq.html#q5
Prinzipiell ist SQLite3 in der Lage mehrere Verbindungen zu erlauben, auch threadsichere Transaktionen können durchgeführt werden. Das Problem, was nezzcarth schon ansprach ist, dass SQLite dafür ursprünglich nicht designed wurde. Gerade wenn es um multiprocessing, threads, shared connections bzw. Threadpools usw. geht wirst du auf Dauer keine freude mit SQLite haben. Spätestens dann, wenn du dich mal entscheiden solltest deine Datenbank in einem anderen Netzwerk zu betreiben ist Sense, da du IMO nicht ohne Weiteres auf diese Datenbank zugreifen kannst, wie man es bspw. mit MySQL machen könnte.
Prinzipiell ist SQLite3 in der Lage mehrere Verbindungen zu erlauben, auch threadsichere Transaktionen können durchgeführt werden. Das Problem, was nezzcarth schon ansprach ist, dass SQLite dafür ursprünglich nicht designed wurde. Gerade wenn es um multiprocessing, threads, shared connections bzw. Threadpools usw. geht wirst du auf Dauer keine freude mit SQLite haben. Spätestens dann, wenn du dich mal entscheiden solltest deine Datenbank in einem anderen Netzwerk zu betreiben ist Sense, da du IMO nicht ohne Weiteres auf diese Datenbank zugreifen kannst, wie man es bspw. mit MySQL machen könnte.
When we say computer, we mean the electronic computer.
@sls: Wenn ein paar Zugriffe pro Tag stattfinden ist das schon viel. Mit MySQL brauche ich erst gar nicht anzufangen, das übersteigt meinen Horizont. Ich werde es einfach mal im Testbetrieb versuchen und hoffe, dass es so funktioniert.
@sls: irgendwie hört sich das in Deinem Link für mich an, als ob man Datenbanken nicht auf einem Netzwerklaufwerk haben möchte; im Widerspruch zu Deinem ersten Post. Bei Datenbanken bin ich immer besonders Vorsichtig, weil Fehlverhalten schwer zu entdecken ist, und wenn, dann sind gleich die ganzen Daten kaputt.
@snowflake: wenn Du irgendwo einen zentralen Rechner hast, schreibe besser eine Serveranwendung, dann gibt es nämlich nur einen Prozess, der auf die Datenbank zugreift und Du hast das Problem gelöst, das Programm verteilen zu müssen.
@snowflake: wenn Du irgendwo einen zentralen Rechner hast, schreibe besser eine Serveranwendung, dann gibt es nämlich nur einen Prozess, der auf die Datenbank zugreift und Du hast das Problem gelöst, das Programm verteilen zu müssen.
-
sls
- User
- Beiträge: 480
- Registriert: Mittwoch 13. Mai 2015, 23:52
- Wohnort: Country country = new Zealand();
Ich ging davon aus, dass er das ohne zentrale Instanz die sich um den Datenbankzugriff kümmert, durchziehen will. Dann muss die Datenbank ja irgendwo auf einem Netzwerk-Share liegen. Ich stimme allerdings zu, dass eine Art DBMS-Implementierung mit Server der die Client-Queries verarbeitet und als einziger auf die Datenbank zugreift, sinnvoller ist.Sirius3 hat geschrieben: Mittwoch 3. Oktober 2018, 12:06 @sls: irgendwie hört sich das in Deinem Link für mich an, als ob man Datenbanken nicht auf einem Netzwerklaufwerk haben möchte; im Widerspruch zu Deinem ersten Post.
@snowflake: ich würde dir trotzdem dringend empfehlen ein Programmiersprachen-unabhängiges MySQL-Tutorial durchzuarbeiten. Allein das Anlegen von Usern, Berechtigungen, Datenbanken erstellen und wählen, Tabellen anlegen, die ganzen Abfragen und Update-Statements... Wenn man das mal verstanden hat, tut man sich auch mit der Umsetzung in Python wesentlich einfacher. MySQL ist plattformunabhängig und quasi so etwas wie der Standard unter Datenbanken, auch wenn Postgres uvm. schwer in Mode kommen.
When we say computer, we mean the electronic computer.
SQLite nutzt zur arbitrierung von Schreibzugriffen File-Locks. Und die wiederum sind ueber Netzwerkshares eher eine Herausforderung. Das wuerde ich nicht wagen. Oder zuerst gruendlich testen, mit wirklichen Stresstests. Denn sonst sind deine Daten ratzfatz korrupt.
Wieso denkst du das denn? So kompliziert ist es eigentlich nicht. Mysql/Mariadb sind m.M.n. gerade auch deswegen (insb. in der PHP-Welt) so beliebt, weil sie vergleichsweise einfach in der Handhabung sind.snowflake hat geschrieben: Mittwoch 3. Oktober 2018, 11:58 Mit MySQL brauche ich erst gar nicht anzufangen, das übersteigt meinen Horizont. Ich werde es einfach mal im Testbetrieb versuchen und hoffe, dass es so funktioniert.
Das funktioniert so lange, bis es das eben nicht mehr tut. Ich hoffe fuer dich, dass das keine relevanten Daten sind, und du den Verlust der kompletten Datenbank mal so eben verkraften kannst. Denn das ist die Konsequenz.snowflake hat geschrieben: Mittwoch 3. Oktober 2018, 11:58 @sls: Wenn ein paar Zugriffe pro Tag stattfinden ist das schon viel. Mit MySQL brauche ich erst gar nicht anzufangen, das übersteigt meinen Horizont. Ich werde es einfach mal im Testbetrieb versuchen und hoffe, dass es so funktioniert.
Das stimmt.Ich w+rde mysql (und php) auch nicht verwenden, wenn ich es mir aussuchen kann. Die Aussage, dass es einfacher in der Handhabung und insb. der Installation/Einrichtung als z.B. postgresql ist, trifft meiner Ansicht nach aber trotzdem zu.Sirius3 hat geschrieben: Mittwoch 3. Oktober 2018, 15:16 Gerade bei PHP sieht man eigentlich ganz gut, warum es nicht immer logische Gründe gibt, warum eine Technologie eingesetzt wird.
@snowflake: Bevor Du unsicher wirst: SQLite ist eine embedded Database, d.h. die nutzt man nur mit *einer* Anwendung, die dann auf alles zugreifen kann – lesend und schreibend. Was große DB-Systeme (wie z.B. Postgres) auf komplexe Dateistrukturen verteilen, bildet SQLite alles in einer Datei ab. Damit wird schon klar, dass es mit mehreren zeitgleichen Schreibvorgängen schwierig wird. Im Netzwerk lässt sich so eine Datenbank nur vernünftig nutzen, wenn es einen vorgeschalteten Prozess gibt, der dann alle Zugriffe regelt. Wenn nur Du Inhalte einstellst und alle anderen lesen, kannst Du SQLite getrost verwenden. Wenn mehrere Nutzer Schreibrechte haben und diese möglicherweise auch zeitgleich nutzen, dann brauchst Du eine andere DB, die für diesen Anwendungsfall konzipiert ist. Ansonsten ist SQLite schlank, schnell und einfach zu nutzen.
@nezzcarth: Die Einstiegshürde bei php ist in der Tat sehr niedrig. Bei darauf basierenden Systemen wie z.B. Wordpress auch. Sobald man bei solchen Anwendungen aber unter die Haube schaut, wird einem bei den meisten Angst und Bange.