Multiuser und Auswertung von Daten aus einer SQLite DB

[Roggi01]

Hallo liebe Community,

um einige erforderliche Arbeitsschritte zu vereinfachen, vergewaltige ich seit längerem Excel als DB.
Jedesmal sind bei Änderungen viel VBA und Anpassungen in den Tabellen vorzunehmen.
Daher suchte ich nun eine Möglichkeit, die Daten in einer relationalen Datenbank zu speichern.
Es gibt jedoch das Problem, dass ich keinen Server für SQL oder MariaDB erhalten werde.

Nun war mein Gedanke, dass ich eventuell SQLite mit Python nutzen kann. Beim genaueren Lesen bin ich über folgende Fallen gestolpert.
Dazu möchte ich kurz die zwei wichtigsten Szenarien bneschreiben.


Szenario 1:
Multiuser:
Es existiert ein großes Tabellenwerk.
Diese Daten möchte ich gerne in einer relationalen Datenbank verwalten.
Seit SQLite 3 kann man ja mittels Pager Modul sicherstellen, dass kein zeitgleicher Schreibvorgang erfolgen kann.
Fraglich ist nur, wenn in der GUI der gleiche Datensatz geändert wurde. Dann ist ja ein Überschreiben der Angaben von Teammitglied A durch die Angaben von Teammitglied B möglich.
Meine Idee wäre, dass vor dem Schreiben/speichern ein Abgleich mit einer Art Timestamp stattfindet.
Dazu muss in der Userform ein Timestamp A hinterlegt werden, wann der Datensatz geöfnet wurde.
In der Datenbank ist in einer Spalte der Timestamp B, wann der Datensatz letzmalig geändert wurde.
Wenn die Änderung nun gespeichert werden soll, ist es doch möglich zu prüfen, ob Timestamp B älter als Timestamp A ist.
Trifft dieses zu, wird geschrieben, ansonsten wird der Datensatz in der Userform aktuaklisiert.
Kann man auf diesem Wege ein ungewolltes überschreiben verhindern?

Szenario 2:
Zusammenführen mehrere SPLiteDB in eine HauptDB:
Ich muss eine Statistik führen, die von 12 Teams mit je 8 bis 10 Mitarbeitern mit Daten gefüllt werden soll.
Dazu habe ich angedacht, jedem Team eine DB zur Verfügung zu stellen.
Alle Datenbanken sind vom Aufbau absolut gleich.
Für die gesamte Auswertung des Betriebes wollte ich die Daten in eine Hauptstatistik (HauptDB) überführen.
Dazu habe ich angedacht, den Autoincrementeintrag in einer gesonderten Spalte mit einem Präfix zu verketten.
(z.B. Team 01_1, Team 02_1, usw.)
Nun wollte ich prüfen, welche die Id mit Präfix in der Hauptdatenbank bereits vorhanden ist. Wenn nicht, soll dieser kopiert und in die Hauptdatenbank eingefügt werden.
Dazu müsste ich bei einer Aktualisierung alle TeamDB in einer Schleife durchlaufen, prüfen und evtl. einfügen.

Ich würde mich freuen, wenn mir der eine oder andere Fachmann die entscheidenden Tipps zur Machbarkeit geben könnte.
Da ich bereits weit über 50 bin, kein Informatiker o.ä. (also reiner Autodidakt), bitte ich um Nachsicht, wenn ich auf Anhieb nicht alles verstehe.
Jedoch gehöre ich zu dem Kreis, der sich in der Weiten des WWW erst einmal nach Lösungen umschaut.

Herzliche Grüße

Roggi

[__blackjack__]

Zu Szenario 1 gleich mal eine wichtige Nachfrage: Wo wird die Datenbankdatei gespeichert? Netzlaufwerke kannst Du im Grunde vergessen.

Im Grunde klingt das alles danach das Du eigentlich einen Server mit einer ”richtigen” Datenbank haben willst. Wenn das nicht geht, dann geht das ganze Projekt halt nicht.

[sparrow]

Und das klingt auch nicht so, als wenn du eine "Hauptdatenbank" haben willst. Du möchtest *eine* vernünftigt strukturierte Datenbank. Sonst holst du dir lauter Folgeprobleme ins Boot.
Ansonsten: das was __blackjack__ sagt.

[Roggi01]

Hallo Blackjack, hallo Sparrow

vielen Dank für Eure schnellen Antworten.


Leider handelt es sich um Netzlaufwerke.
Jedes Team hat ein eigenes Verzeichnis im Netzlaufwerk.
Ich habe Zugriff auf alle Verzeichnisse.

Und ja, viel lieber einmal eine richtige DB aufsetzen und vernünftig arbeiten können.
Stattdessen zig Tabellen, Listen usw., eine enorm redundante Datenspeicherung.

Habt Ihr eine Idee, wie man das Problem mit den mir zur Verfügung stehnden Mitteln lösen könnte?

Wäre es möglich, jeden User mit einer Datenbank auszustatten und die Hauptdatenbank über attach o.ä. zu befüllen?

Gruß

Roggi

[nezzcarth]

An sich finde ich die Idee mit Python und SQLite gut, aber wenn du in der Microsoft-Welt bleiben möchtest, wäre die "nächste Evolutionsstufe" wohl MS Access. Evtl. sind hier ein paar Infos enthalten, die dir Ansatzpunkte geben könnten: https://support.microsoft.com/en-us/off ... da245a0446 ?

[sparrow]

@Roggi01: Naja, was sind denn deine Mittel? Datenbanken auf Netzlaufwerken sind immer die schlechteste Lösung und die gehen meiner Erfahrung nach gerne mal kaputt bzw. werden seltsam gelockt. Auch Access.

Ich verstehe auch das Problem nicht, eine Datenbank aufzusetzen. Ich kenne Umgebungen da laufen die auf NAS-Geräten weil die nicht so sehr belastet werden.
Wenn da schon ein File-Server läuft, dann muss der ja auch nicht nur Fileserver sein.

[grubenfox]

An sich finde ich die Idee mit Python und SQLite gut, aber wenn du in der Microsoft-Welt bleiben möchtest, wäre die "nächste Evolutionsstufe" wohl MS Access. Evtl. sind hier ein paar Infos enthalten, die dir Ansatzpunkte geben könnten: https://support.microsoft.com/en-us/off ... da245a0446 ?

Unbedingt den Punkt "Share a split database" beachten und das ganze in Backend (enthält nur die Daten) und Frontend (die GUI) aufteilen. Damit kann man dann an der GUI Änderungen vornehmen ohne die Daten zu verändern. Und jedes Team sollte eine lokale Kopie der GUI auf ihren Team-Rechner nutzen. Ich gehe jetzt von aus das jedes Team nicht nur eigene Verzeichnisse hat, sondern auch eigene Rechner.

Was ich noch nicht ausprobiert habe: wie der Zugriff von Access auf SQLite funktioniert. Vielleicht könnte man als Backend anstelle von Access sogar SQLite nutzen.

Das erstellen von Berichten und Auswertungen ist mit Access IMHO teilweise einfacher als mit Python. Jedenfalls waren früher meine Versuche mit ReportLab nicht von Erfolg gekrönt. Falls man heutzutage etwas anderes nutzt, könnte ich es ja mal wieder probieren...

[__deets__]

Ich halte das alles für einen Versuch, mit Technik ein organisatorisches Problem zu lösen. Das hat nur beschränkt viel Aussicht auf Erfolg. Es ist schade, dass jemand, der offensichtlich Energie und Befähigung hat (formale Ausbildung hin oder her, ist ohne Interesse am Thema auch nix wert) dadurch ausgebremst wird. Denn wenn statt Technik aus den 90ern (Einzelplatz-Software mit GUIs) eine Webanwendung genutzt würde, wäre das Ganze deutlich robuster umsetzbar. Es wäre also eigentlich besser, wenn man das Verbot einer solchen Anwendung angehen könnte.

So oder so aber ein Wort der Warnung: Leute reagieren immer SEHR empfindlich darauf, wenn man ihnen etwas wegnimmt. Eine Freundin hat versucht, bei einem großen Pharma-Konzern Excel als universellen Faustkeil mit einer Fachanwendung abzulösen. Das ist gescheitert. Letztlich wurde daraus nur ein Macro-Satz, der die Daten zur Revisionierung abgezogen hat. Mehr war nicht drin. Egal was du also anfängst: bezieh deine User frühzeitig ein, damit du überhaupt buy-in und Willen, sich in was Neues einzuarbeiten bekommst.

[noisefloor]

Hallo,

da du dich scheinbar in einem Microsoftumfeld bewegst: würdest du denn einen MS SQL Server bekommen? AFAIK sind die "kleinen" Versionen kostenfrei nutzbar?

SQLAlchemy kann auch mit SQL Server umgehen, von daher wäre auch die Anbindung an Python kein Problem.

Gruß, noisefloor