SQLite - Wie Multiuser Zugriff regeln?

[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: