Datendefinition der DB im Programm prüfen

[hoika]

Hallo,

Zitat:

der erste Client updatet die DB, uns für die anderen passt es dann schon.

Hoffentlich startet der 2. Client nicht auch das DB-Update, weil der 1. Client noch nicht fertig ist,
und deshalb die DB-Version noch nicht hochgezählt hat.

[Schokohase]

Zitat:

Zitat von hoika (Beitrag 1412811)

Hallo,

Zitat:

der erste Client updatet die DB, uns für die anderen passt es dann schon.

Hoffentlich startet der 2. Client nicht auch das DB-Update, weil der 1. Client noch nicht fertig ist,
und deshalb die DB-Version noch nicht hochgezählt hat.

Aus dem Grund empfiehlt es sich eine eigenständige kleine Anwendung zu schreiben, die nur das Update der Datenbank erledigt. Die Datenbank selber sollte Strukturänderungen auch nur einem bestimmten Nutzerlevel gestatten und nur diese können dann das Update durchführen.

Wenn jeder Client die Änderungen vornehmen kann, dann impliziert das, es kann auch jeder User Strukturänderunegn vornehmen. Klingt irgendwie nicht gut.

Noch sinnvoller ist es natürlich eine (REST)API dazwischen zu legen. Dann kann diese API-Anwendung die Datenbank anpassen und für die unterschiedlichen Client-Versionen die korrekten APIs anbieten oder eben auch ganz abschalten und damit zum Update zwingen.

[TigerLilly]

Zitat:

Hoffentlich startet der 2. Client nicht auch das DB-Update, weil der 1. Client noch nicht fertig ist,
und deshalb die DB-Version noch nicht hochgezählt hat.

Nein, das tut er nicht, da achtet die Klasse schon drauf.

Zitat:

Aus dem Grund empfiehlt es sich eine eigenständige kleine Anwendung zu schreiben, die nur das Update der Datenbank erledigt. Die Datenbank selber sollte Strukturänderungen auch nur einem bestimmten Nutzerlevel gestatten und nur diese können dann das Update durchführen.

Ich habe beschrieben, wie wir das machen + was für uns + unsere User gut funktioniert. Das mag für dich gern anders sein.

Zitat:

Klingt irgendwie nicht gut.

:shock:

Zitat:

Noch sinnvoller ist es natürlich ...

:roll:

[Schokohase]

@TigerLilly

Habe ich irgendwo behauptet, dass deine Variante nicht funktioniert?

Ich habe eine Empfehlung gegeben weil @hoika berechtigterweise auf potentielle Problematiken hingewiesen hat.

Meine Empfehlungen beziehen sich darauf und auf das Thema generell.

Wenn du die Augen vor dieser Problematik verschliessen möchtest (warum auch immer) dann verschliesse sie doch auch bei meinem Beitrag.

[Delphi.Narium]

@Schokohase

Woher weißt (ahnst) Du, dass alle hier genannten Einwände, potentiellen Probleme ... nicht bereits von TigerLillys Klasse berücksichtigt werden und eventuell sogar weit über alle hier genannten möglichen Stolpersteine hinausgeht.

Mir scheint jedenfalls nach der Beschreibung von TigerLilly da schon ziemlich viel Gehirnschmalz in der Klasse zu stecken, so dass ich nicht davon ausgehe, dass sie hier irgendwie die Augen verschließt.

Mein Vorschlag:

Wer 'ne Idee zum Thema hat, stelle sie hier vor.

Keine Kritik an den Ideen anderer.

Der Threadersteller hat das Knowhow, um die Ideen selbständig zu analysieren und die für seinen Belange beste Kombination daraus zu erstellen.
Ist sicherlich deutlich effektiver als sich über eventuell bestehende Fehermöglichkeiten und / oder Schwachstellen zu streiten.

[hoika]

Hallo.

Zitat:

Nein, das tut er nicht, da achtet die Klasse schon drauf.

Und wie?
Die Frage stelle ich, weil ich auch vor dem Problem stehe.
Hast Du das Datenbank-neutral gelöst?

[Hobbycoder]

Zitat:

Zitat von Delphi.Narium (Beitrag 1412825)

Der Threadersteller hat das Knowhow, um die Ideen selbständig zu analysieren und die für seinen Belange beste Kombination daraus zu erstellen.
Ist sicherlich deutlich effektiver als sich über eventuell bestehende Fehermöglichkeiten und / oder Schwachstellen zu streiten.

Hat er ;-)

Ihr habt mir einige Anregungen gegeben, die ich mir alle angesehen habe.

Stand zur Zeit:
Ich möchte keine weiteres Tools einsetzen, deshalb mache ich dann doch alles selber. Auch wenn diese Tools durchaus gut sind und mit Sicherheit vieles auch noch besser machen, als ich, so geht das doch oft über meine Anforderungen hinaus, bzw. verursacht weitere Kosten, die ich vermeiden kann.

In einer Tabelle lege ich mir die Version der DB an (der Einfachheit halber nutze ich dafür die Programmversion, warum erzähle ich später).
Beim Programmstart wird auf DB-Version<Programmversion geprüft. Ist diese größer, so wird die Datenbank überprüft. Ich prüfe jede Tabelle und jedes Feld. Dazu habe ich mir eine Klasse geschrieben, die alle Tabellen und Felddefinitionen enthält, diese validieren kann und auch die gewünschten Operationen durchführen kann.
(Löschen von Tabellen oder Feldern wird mit Sicherheit eine Ausnahme bleiben, und wahrscheinlich nur zwei, drei mal, wenn überhaupt, vorkommen. Und bei Änderungen wird es auch nur mal eine Feldvergrößerung sein)

Weiterhin hat die Klasse die Möglichkeit in Abhängigkeit von Operationen oder bestimmten Versionsnummern auch SQL-Scripte auszuführen.
Somit sind da doch all meine Anforderungen erfüllt.

Zum Thema "an mehreren Clients updates gleichzeitig". Nun, das sollte ja logisch sein, dass man sowas berücksichtigen muss. Aber auch dort habe ich keine Bedenken.
Da sich die Clients in einer Benutzertabelle anmelden müssen, wird natürlich als erstes geprüft, ob andere Clients angemeldet sind. Ist dies der Fall werden diese Benachrichtigt und gewartet, bis alle Clients sich ordnungsgemäß abgemeldet haben. Erst dann kann das DB-Update gestartet werden. Dann wird natürlich auch ein Updateflag in die DB geschrieben, welches eine später Anmeldung während des Update-Vorgangs verhindert.
Somit sollte sichergestellt sein, dass kein Client mehr aktiv mit der DB arbeitet.

Sicherlich hat mein Konzept Lücken und auch Schwachpunkte. Aber ich denke ich kann damit sehr gut leben.
Das wichtigste ist vorab umgesetzt: Die Sicherung der kompletten Datenbank ;-)

Achja, warum nehme ich die Programmvesion als Datenbankversion.
Das Programm wird nur ca. alle 3 Monate als Update ausgeliefert. Eine der häufigsten Änderung ist in den erstellen Indizes, da für neue Berechnungen weiter Indizes hinzukommen. Deshalb lasse ich die DB in dem Zuge auch gleich überprüfen, was das Neuerstellen der Indizes beinhaltet. Somit brauch ich keine weitere Versionsnummer. (innerhalb der Entwicklung löse ich das anders).

[Schokohase]

@Delphi.Narium

Wenn der Client beim Start die Datenbank-Struktur untersucht / Version vergleicht und dann im Bedarfsfall die Datenbank-Struktur verändert, dann muss der Datenbank-Benutzer, den der Client verwendet, das Recht haben die Datenbank-Struktur zu verändern.

Das ist ein potentielles Sicherheitsproblem und halte ich darum für keine gut Idee.

Wer das vernachlässigen kann, soll es machen. Wer die Verantwortung trägt trifft auch die Entscheidung.

[Delphi.Narium]

Zitat:

Zitat von Schokohase (Beitrag 1412829)

@Delphi.Narium

Wenn der Client beim Start die Datenbank-Struktur untersucht / Version vergleicht und dann im Bedarfsfall die Datenbank-Struktur verändert, dann muss der Datenbank-Benutzer, den der Client verwendet, das Recht haben die Datenbank-Struktur zu verändern.

Das ist ein potentielles Sicherheitsproblem und halte ich darum für keine gut Idee.

Wer das vernachlässigen kann, soll es machen. Wer die Verantwortung trägt trifft auch die Entscheidung.

@Schokohase

Deine Anmerkung halte ich für so selbstverständlich, dass ich nicht davon ausgehe, dass Leute, die derartige Software erstellen, nicht darauf achten.

Hier reden keine unbedarften Hoppyprogrammierer über eine Datenbankänderung, sondern Profis, mit vermutlich einigen zig Jahre(zehnt)n an Berufserfahrung.

[TigerLilly]

Zitat:

Zitat von Schokohase (Beitrag 1412829)

Das ist ein potentielles Sicherheitsproblem und halte ich darum für keine gut Idee.

In deiner Welt + mit deinem Code vielleicht. Aber schließ nicht von dir auf andere.

Bei unserer APP ist der User, der mit der App arbeitet vom Login/User in der DB getrennt. Das heißt, die App hat einen eigenen DB USer, mit dem sie sich an die DB verbindet, der Benutzer der Software braucht selbst am DB Server gar keine Rechte. So ist sicher gestellt, dass wirklich nur die APP Änderungen an der DB durchführen kann.

Wir haben vorwiegend mit Benutzer/innen zu tun, die keine IT Abteilung um sich herum haben, sondern alles selber machen. Und da ist es wichtig, dass möglichst viel von dem DB Zeugs im Hintergrund und automatisch läuft.