SQLite - Wie Multiuser Zugriff regeln?

[Satty67]

Hallo,

eine Anwendung (Fuhrpark-Verwaltung) speichert Daten in einer SQL-Datenbank. Über eine Zwischenschicht (einfach ein Object, dass die Daten bereitstellt) wird nun die Möglichkeit geboten MSSQL, Firebird oder SQLite zu verwenden.

Grundsätzlich empfehle ich, SQLite nur für Einzelplatz-Rechner zu verwenden, will aber auch hier eine Notlösung für 2-3 Clientrechner bieten.

Es wird meistens lesend auf die Datenbank zugegriffen. Schreibzugriffe bei neuem Fahrzeug, Werkstattbesuche oder Verbrauchswerte eingetragen oder neue Bilder eingefügt werden. Denke also, das es sehr selten zu Schreibkollisionen kommen wird.

Meine Lösung über eine Lock-Table ist für SQLite nicht sicher, da ja kein zentrales DBMS den Zugriff regelt, sondern dezentral die Clientrechner per DLL auf die DB zugreifen. Im worst-case locken zwei Clientrechner die gleiche Tabelle/Datensatz.

***

Meine erste Idee und bisher einziger Ansatz ist, das ich eine Datei zur Datenbank mit anlege. Also neben Daten.sqlite noch eine Daten.lock. Diese Datei Daten.lock wird vom Clientrechner exclusiv (ShareDenyAll) geöffnet, bevor ein Schreibzuriff innerhalb der Daten.sqlite erfolgt.

Welche Lösungen würde Ihr vorschlagen?

[alzaimar]

Zitat:

Zitat von Satty67 (Beitrag 1065425)

Welche Lösungen würde Ihr vorschlagen?

Keine.

Wieso bietest Du überhaupt unterschiedliche DB an? Was Du da machst, hat weder Hand noch Fuss. Du läufst mit so einer Krückenlösung Gefahr, das der Kunde sich die Datenbank zerschießt.

Schmeiss SQLLite doch einfach aus dem Portfolio und verwende nur FB, und von mir aus auch MSSQL (aber wieso eigentlich?).

[Bernhard Geyer]

Zitat:

Zitat von alzaimar (Beitrag 1065438)

... und von mir aus auch MSSQL (aber wieso eigentlich?).

Wenn man nur ein DB anbietet so ist man auch für die nachgelagerten Jobs wie Backups, ... verantwortlich.
Hat man ein DB im Angebot die der Kunde eh schon hat (i.d.R. MS SQL Server, MySQL oder Oracle) so kann man diese Installation verwenden und somit auch vorhandene Backupmechanismen, ...

[Satty67]

Zitat:

Zitat von alzaimar (Beitrag 1065438)

Wieso bietest Du überhaupt unterschiedliche DB an?

Weil es geht... der Zugriff auf SQL-Server Datenbanken ist problemlos und wird über ein jeweils aufs DBMS spezialisiertes Objekt geregelt, es werden auch noch weitere Datenbanken dazu kommen. Innerhalb des Programmes gibt es eine genormte Schnittstelle zum Daten-Objekt, XML usw. wird darüber auch angesprochen werden. (vgl. Linq)

Das ist aber unwichtig...

Die Frage ist nur, wie ich einen sicheren Multiuser-Zugriff mit SQLite lösen könnte.

Gibt es keine sichere Lösung, wird es Singleuser beschränkt, aber auf jeden Fall drin bleiben.

// Es wäre Schade, wenn die Diskussion an der Frage vorbeiläuft, weil ich das aktuelle Einsatzgebiet gleich mit beschrieben habe.

[Florian Hämmerle]

Du könntest eine Liste dazugeben, welche Tabellen gerade in Gebrauch sind. Ist das der Fall bekommt der zweite, der auf die Tabelle zugreifen möchte eine Meldung angezeigt, dass er es in einigen Sekunden noch einmal versuchen soll.

mfg Florian

[himitsu]

Einfache Lösung?
SQLLite nur für SingleUserSysteme.

Sobald es mehr wird, dann ein richtiges DBMS nutzen, welches von sich aus MultiUser anbietet.

[Satty67]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1065451)

Du könntest eine Liste dazugeben, welche Tabellen gerade in Gebrauch sind.

Eine einfache Variante ist meine aktuelle Idee (via gelockter beliegender Datei). Es darf schon unkomfortabel sein, also muss nicht Tabellen einzeln sperren, sondern die ganze Datenbank ist völlig Ok. Denke werde in der Richtung mal weiter testen. (Die *.sqlite Datei selbst kann ich leider nicht "sporadisch" sperren)

Wie himitsu auch geschrieben hat, für richtiges Multiuser muss ein Server-System verwendet werden. Es wäre nur gut, wenn mit SQlite eine Art Basis-Muliuser-Zugriff möglich wäre z.B. für Heimnetzwerke ohne Server.

[Mithrandir]

Zitat:

Zitat von alzaimar (Beitrag 1065438)

Wieso bietest Du überhaupt unterschiedliche DB an?

Wir haben auch einige Kunden, die uns an die Gurgel springen würden, täten wir nicht MSSQL und Oracle unterstützen. Nichtsdestowenigertrotz ist der Einsatz von SQLite für eine Multiuser-Umgebung - Pardon - schwachsinnig.

Ich würde nicht anfangen, mir eine Lösung zusammenzufrickeln, nur weil ich unbedingt bei SQLite MU brauche. Wenns für den Kunden billig sein soll, dann würde ich ihn eher dazu anhalten, MySQL zu installieren, wenn er eine MU-Umgebung benötigt. Das müsstest du natürlich noch unterstützen, ist ja aber nichts unmögliches.

[Satty67]

Ja, es sollen viele DBMS unterstützt werden, gruppiert nach Fähigkeiten.

Wenn es zu riskant ist, dann schiebe ich SQlite in die SingleUser-Gruppe zusammen mit XML, INI usw. (letztere sind sogar nur SingleTable)

[webcss]

Schau Dir mal die Patterns Optimistic-Offline-Locking oder Pessimistic-Offline-Locking an. Die könnten Dir weiterhelfen.

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1065453)

Einfache Lösung?
SQLLite nur für SingleUserSysteme.

Sobald es mehr wird, dann ein richtiges DBMS nutzen, welches von sich aus MultiUser anbietet.

Ich sekundiere himitsu! :thumb:

[Sir Rufo]

Wenn man SQLite unbedingt MU-fähig machen will, dann müsste man eine entsprechende Zwischenschicht drüberlegen (z.B. SOAP)

Ist aber wohl mit Kanonen auf Spatzen und wesentlich billiger zu haben ;)
(MSSQL-Express)

[Satty67]

Zitat:

Zitat von webcss (Beitrag 1065513)

Optimistic-Offline-Locking/Pessimistic-Offline-Locking

Klingt ganz allgemein sehr interessant

Zitat:

Zitat von Sir Rufo (Beitrag 1065520)

Wenn man SQLite unbedingt MU-fähig machen will

Unbedingt nicht... aber versuchen wollte ich es. MSSQL-Express (bzw. Compact) und Firebird-Server laufen hier auf der Testumgebung und werden natürlich mit angeboten.

[mschaefer]

Grundsätzlich kanst Du mit einer SOA-Schicht vom Prinzip her jede Datenbank Multiuserfähig bekommen. Also auch Access, DBase und Paradox, aber letztlich immer mit großen Einschränkungen, was die Wartezeit der User betrifft. Und die SOA-Schicht brauchte wieder eine eigene Installation, wie ein DB-Server. Damit sind dann alle Vorteile gegenüber einem richtigen DBMS zunichte.

Grüße

[sh17]

Zitat:

Zitat von mschaefer (Beitrag 1065533)

Grundsätzlich kanst Du mit einer SOA-Schicht vom Prinzip her jede Datenbank Multiuserfähig bekommen. immer mit großen Einschränkungen, was die Wartezeit der User betrifft.

Meinst Du? Ich denke bei größtenteils lesenden Zugriffen könnte es sogar schneller werden, da ja die User nur noch das vom Server bekommen, was sie wollen und nicht die ganze Tabelle öffenen müssen.

[mschaefer]

Ja meine ich, den hinter der SOA werkelt immer noch eine Single Usr DB und die kümmert sich nicht um Caching. Diese Aufgabe der SOA-Schicht zu verpassen würde bedeuten, diese die Datenbankabfragen vergleichen zu lassen, um zu entscheiden ob exakt die Daten vorliegen, die neu angefordert werden. Also müßte man in der SOA ein eigenes DBMS integrieren. Das ist dann aber nicht mehr "SQLite" sondern was komplett neues.

Morgengrüße // Martin

[Satty67]

Also Geschwindigkeit ist für den Anwendungsfall sekundär.

Es soll kein allgemeiner Ersatz für einen optimierten Zugriff auf eine festgelegte SQL-Datenbank werden, sondern ist für kleinere Projekte (von der Datengröße) gedacht.

Es soll ein von der Datenquelle unabhängiger Zugriff möglich sein. Je mehr ich bei den Datenquellen auf einen gemeinsamen Nenner bringen kann, desto weniger muss ich auf Applikationsseite berücksichtigen. Deshalb der Versuch...

Mit eingeschränkter Funktionalität, weil noch etwas zu stark auf das aktuelle Projekt zugeschnitten, funktioniert es bereits wunderbar. Ich werde es die Tage zu einem allgemeineren System umbauen und dann vorstellen.

[Satty67]

Zitat aus diesem Thread:

Zitat:

Zitat von Hansa (Beitrag 1065956)

Ihr seid bekloppt. :lol:

[...]

Ungefähr so ähnlich wie die Cracks, die hier 10 DBMS unterstützen wollen. Aber wozu ? Meine Schlüsse wären folgende : der hat sich verzettelt. Weiss zwar viel aber nichts richtig. 8-)

Dort OT, deshalb die Antwort hier:

SQL, LINQ, TDataSet/TDataSource usw. ...alles Lösungen, die den Datenaustausch mit Datenbanken/Datenspeicher entweder in Sprache oder Schnittstelle normieren. Ich versuche nur, die Schnittstelle näher (oder weiter weg?) an der Datenbank anzusiedeln, dass wirklich keine spezifischen Eigenschaften mehr beachtet werden müssen. Die nötigen Kompromisse sehe ich und nehme die in Kauf.

Letztlich kann ich ein Zitat von Sir Rufio drehen: "Mein Projekt, Mein Problem" ;)

[Assarbad]

Daß es möglich ist, hat niemand bezweifelt. Aber irgendwie geht mir hier unter, daß SQLite dafür einfach nicht das richtige Werkzeug ist.

Man kann einen Metzger sicher auch in einen OP-Saal stellen, aber die Ergebnisse werden zweifelhaft sein. Ähnliches gilt umgekehrt, daß man einen Hirnchirurgen in ein Schlachthaus oder eine Metzgerei stellen kann. Alles möglich, aber nicht zwangsläufig zweckmäßig.

Man kann sicher auch bis zu einem gewissen Grad einen Hammer zu Reparaturen (das abstrakte Problem) einsetzen. Es handelt sich also für den Zweck um ein bedingt einsetzbares Werkzeug. Aber die hiesige Argumentation ist vergleichbar damit jetzt nicht etwa die Werkzeugkiste zu erweitern, sondern mehr Hämmer zu benutzen. Mir bleibt die Spucke weg.

[Sir Rufo]

Allerdings kann man einen Gynäkologen hervorragend als Maler einsetzen.

Der kann den Flur streichen ohne dass ihm die Tür geöffnet wird.
Alles nur durch den Briefschlitz.

:mrgreen:

[Satty67]

Zitat:

Zitat von Assarbad (Beitrag 1066040)

Daß es möglich ist, hat niemand bezweifelt. Aber irgendwie geht mir hier unter, daß SQLite dafür einfach nicht das richtige Werkzeug ist.

Hier werden zwei Dinge vermischt und dadurch eine für mich nicht nachvollziehbare Bewertung der aufgetauchten Projekt-Details abgegeben.

SQLite muss nicht Multi-User fähig werden, es wurde nur die Frage gestellt ob es möglich wäre und wenn ja wie. SQLite passt natürlich auch als SingeUser Datenbank ins Konzept. Wer meine Idee genau angeschaut hätte, hätte vielleicht auch gesehen, das bei meinem "MultiUser"-Ansatz auch immer nur ein exlusiver Schreibzugriff erfolgt wäre.

Das hat aber nichts mit der Gesamt-Idee zu tun, die jeder hier schon in spezialisierter Form bereits nutzt und von mir nur unspezifischer umgesetzt werden soll. Hier wird genauso banal kritisiert, obwohl es genau betrachtet nur einen Schritt neben bestehenden und bereits intensiv genutzten Systeme stehen soll.

Wer DB Zugriffskomponenten wie ZEOS etc. nutzt, kann sich ja mal anschauen, wie er in einer einfachen Anwendung auf MSSQL, Firebird oder SQLite zugreift und welche Befehle er nutzt. Kann sich Fragen was der Sinn hinter SQL/SQL-92 war... und sich am Ende vielleicht wie ich fragen, warum hier zwingend so strickt unterschieden werden muss.

***

Ich hab' keine Lust mehr das weiter zu verteidigen (man wird ja sowieso als bekloppt abgestempelt).
Ihr findet es Mist und gut ist, wenn es in meinen Projekten gut arbeitet reicht mir das.

[Assarbad]

Zitat:

Zitat von Satty67 (Beitrag 1066080)

Wer DB Zugriffskomponenten wie ZEOS etc. nutzt, kann sich ja mal anschauen, wie er in einer einfachen Anwendung auf MSSQL, Firebird oder SQLite zugreift und welche Befehle er nutzt. Kann sich Fragen was der Sinn hinter SQL/SQL-92 war... und sich am Ende vielleicht wie ich fragen, warum hier zwingend so strickt unterschieden werden muss.

Standardisierung, würde ich meinen. Kenne nur wenige die darauf wert legen nur diese Untermenge zu benutzen. Als ich mit SQLite angefangen hatte, wurde ich augenrollend von einigen Kollegen mit schiefen Blicken bedacht.

Zitat:

Zitat von Satty67 (Beitrag 1066080)

Ich hab' keine Lust mehr das weiter zu verteidigen (man wird ja sowieso als bekloppt abgestempelt).

Gerade das hatte ich versucht zu vermeiden. Tut mir leid, wenn es so rüberkam.

[Satty67]

Zitat:

Zitat von Assarbad (Beitrag 1066094)

Tut mir leid, wenn es so rüberkam.

Du warst nicht gemeint, sorry wenn Du durch das Zitat am Anfang meines letzten Posts für Dich den Eindruck hatte.

***

Das Ausgangsproblem (Fragestellung in Post #1) habe ich gelöst, wie es alle lösen:

Multi-User-Zugriff <> Parallel-Zugriff

In einem Multi-User System können mehrere User eine Datei bearbeiten (nicht gleichzeitig, aber nacheinander). Liegt ein Bild/Dokument etc. auf einem Netzlaufwerk, dann kann ich es auf Client-PC #1 bearbeiten und danach auf Client-PC #2.

Bearbeitungsprogramme setzen beim Öffnen das Bild auf ShareDenyWrite. Dadurch kann man sich während Client-PC #1 bearbeitet auf Client-PC #2 ein SnapShot holen, aber nicht parallel bearbeiten.

Mit dem verwendeten Wrapper für SQlite3.dll hatte ich keine interne Lösung entdecken können. Deshalb löse ich das zumindest innerhalb meiner Anwendung mit einer parallel beiliegenden Datei. Somit stelle ich sicher, wenn auf die Datenbank von unterschiedlichen Usern/Client-PC zugegriffen wird, kein kollidierender Schreibzugriff herrscht.

***

Das andere im Thread hochgekommene Thema (Uni-Zugriff auf mehrere DBMS) soll entsprechend den Forenregeln hier nicht weiter Thema sein.