Wenn jetzt zeitgleich mehrere auf die SQL direkt zugreifen, kann's zu Fehlern kommen in der Datenbank und wenn man dann noch Glück hat, stürzt die Software dazu ebenso ab :)
Diese Aussage hat jemand in der mAirList Facebookgruppe geschrieben. Stimmt das? Eigentlich ist doch gerade eine SQL Datenbank dazu da, dass mehrer gleichzeitig darauf zugreifen können.
Hintergrund meiner Frage ist, das wir hier aktuell ebenfalls eine SQL Datenbank nutzen, diese liegt auf unserem Webserver, also beim Webhoster. Darauf greifen wir mit dem Senderechner über das Internet zu und auch mit einem zweiten System welches wir im Studio als “Musikredaktion” nutzen, also um arbeiten an der Datenbank auszuführen. Es wird aber auch mobil (Notebook) als Livessystem genutzt.
Ist diese Konstellation nun potenziell “gefährlich” oder “problematisch”?
Absolut ungefährlich. Und auch für den Mehrbenutzerbetrieb gemacht. Gar kein Problem.
Vermutlich bezog sich die Aussage auf das “Teilen” einer lokalen Datenbank (*.mldb), wenn diese auf einem Netzlaufwerk abgelegt wird. Davon ist explizit abzuraten.
Moin elvis,
Nein, das ist ausgemachter Schwachsinn und genau solche Beiträge sind es, warum ich diese Gruppe wieder verlassen habe.
Du siehst das genau richtig, ein SQL Server ist genau dazu da, dass mehrere Clients auf die Daten zugreifen können. Dabei ist es völlig egal ob MySQL, PostgreSQL, MS-SQL am Start ist.
Das sind alles reinrassige SQL Server, die durchaus zig Clients gleichzeitig bedienen können und damit meine ich hunderte oder gar tausende gleichzeitiger Zugriffe, je nach Leistungsfähigkeit der Hardware unter dem SQL Dienst.
Die lokale Datenbank von mAirlist, die eine SQLite Datenbank ist, ist da grundlegend anders. Dort ist ein Datei basierender Zugriff, der bei mehreren Zugriffen, zu Konflikten führen kann. Darum heißt das ding ja auch lokale Datenbank und die anderen Netzwerk Datenbank, innerhalb von mAirlist.
Noch zwei Ergänzungen zu der ausführlichen Erklärung von Malte:
Auch bei netzwerkbasierten SQL-Servern kann es natürlich zu Konflikten kommen, wenn zwei Prozesse gleichzeitig an derselben Stelle schreiben wollen. Der Server versucht es aber auszubügeln (Stichwort: Serialisierung). Nur in sehr seltenen Fällen sieht man mal einen Fehler “cannot serialize query” o.ä.
Die lokale Datenbank (SQLite) benutzt die File-Locking-Mechanismen des Dateisystems, um gleichzeitige Zugriffe gegeneinander abzusichern. Daher kommt es sehr schnell zu Meldungen wie “database is locked”, wenn man mit mehreren Prozessen auf die gleiche Datei zugreift. Bei Netzlaufwerken ist es so, dass die Locking-Mechanismen teilweise nicht korrekt implementiert sind; da kommt es dann tatsächlich zu Beschädigungen der Datenbankdatei.
If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.