|
Datenbank: MySQL • Version: 5.6 • Zugriff über: UniDAC
Datendefinition der DB im Programm prüfen
ich brauch mal Anregungen von euch.
Zu einem Programm gehört eine DB, die sich mit neuen Version des Programms erweitert/verändert. Passiert ja schon mal ;-) Ich möchte beim Programm start die DB überprüfen, ob alle Tabellen vorhanden sind oder welche gelöscht werden können, und ob alle Felder korrekt sind oder verändert werden müssen. Das ist vom Prinzip her ein Problem, das mach ich schon seit Jahren in einer Anwendung und läuft perfekt. Nun wird die Anwendung aber komplett neu aufgebaut (es gibt verschiedene Gründe dafür, die aber mit der Frage nichts zu tun haben), und ich mache mir erneut Gedanken darüber, wie ich das elegant lösen kann. Ich will also meiner Anwendung Informationen über die Datenbankstruktur mitgeben. Entweder als Datei, als Konstanten oder als Resource. Nur über die Struktur mache ich mir noch Gedanken. Ich möchte folgende Fälle integrieren können:
Vielleicht gibt es für sowas ja schon was schickes, was ich da Verwenden kann. Zur Zeit sind meine Überlegungen bei einem einfachen Textformat. z.B so:
Code:
+ für Hinzufügen, - für Löschen und / für Ändern. Dahinter jeweils Information um was für ein Objekt es sich handelt und danach dann die entsprechenden Definitionnen.
+Table user
+Table config -Table users /Table MA Mitarbeiter +Field user ID Int 0 0 * * "" +Field user Name varchar 100 0 - * "" -Field user Username /Field user VName varchar 100 0 - * "" > Vorname varchar 200 0 - * "" +Index user ID,Name Nur bevor ich mir jetzt die Arbeit mache das umzusetzen, will ich noch mal schauen, ob das nicht besser geht. Natürlich habe ich auch darüber nachgedacht, DDL zu verwenden. Aber ich möchte das nicht direkt an den SQL-Server schicken und dem das überlassen, sondern über mein Programm laufen zu lassen und eine Interaktion mit dem Benutzer zu ermögliche. |
AW: Datendefinition der DB im Programm prüfen
Moin...8-)
Ich finde es ist besser, im Programm ein Differenzscript (SQL) auf die DB loszulassen. In der DB muß die aktuelle DB Version stehen (Tabelle). Der Updater liest die Versionstabelle aus und führt die Scripte in der Reihenfolge bis zur aktuellen Version aus. ...Fertsch. :wink: Zitat:
|
AW: Datendefinition der DB im Programm prüfen
Zitat:
|
AW: Datendefinition der DB im Programm prüfen
Zitat:
Deswegen möchte ich ja einen Soll-Stand mit einem Ist-Stand vergleichen um dann gezielt nur die Änderungen auszuführen. Was ich geschrieben habe mit dem Ändern von Tabellennamen oder Feld-Definitionen, das kommt eher seltener vor (Kann aber, und daher will ich das gleich vorsehen). Interaktion kann auch bedeuten: Detaillierte Fortschrittsanzeige, oder z.B. bei Datenmanipulation die Frage: Jetzt gleich oder später nochmal nachfragen o.ä. |
AW: Datendefinition der DB im Programm prüfen
Zitat:
Zitat:
Habe mal ein Projekt mit Entity Framework 6 und Migrationen gemacht, da hat das super funktioniert. Falls man eine Relation von 1:1 zu 1:n gewachsen ist: Neue Tabelle anlegen, SQL Befehl um die Daten zu kopieren und alte Tabelle anpassen. Ist eine Migration und man kann auch eine Rückmigration machen, wenn man die Funktion auch befüllt :-) |
AW: Datendefinition der DB im Programm prüfen
Evtl. wäre ein ORM Mapper was für dich? Damit könntest du die Strukturen via Objektattribute bestimmen. Das System kann dann die Struktur deiner Objekte auf die DB mappen und ggf. die Datenbankstruktur anpassen.
 https://www.tmssoftware.com/site/aurelius.asphttps://bitbucket.org/soundvibe/marshmallow/wiki/Homeund natürlich einige weitere, aber das sind die, die ich bisher getestet habe. Aurelius läst sich meiner Meinung nach besser an bestehende Datenbanken anpassen. Die Zugriffe funktionieren performant. Sping4D ist OpenSource, hat aber nicht so viele Möglichkeiten wie Aurelius. Aber es wird stetig an beiden ORMs weitergearbeitet (mein Eindruck) und immer wieder verbessert. |
AW: Datendefinition der DB im Programm prüfen
Zitat:
Man braucht eine definierte Zielvorgabe. Das wäre die einzig sinnvolle Grundlage für alle Änderungsvorgänge. Für die Vorgabe kann man verschiedene Möglichkeiten nutzen, z.B. ein leeres DM Script, ggF. mit teilweise gefüllten Konfigurationsdaten (Default Customization) Dann kann es diese Zielvorgabe auch in abstrakter Form geben, also bspw. eine Versionstabelle, die modulweise die vorhandenen Versionen anzeigt plus mögliche Upgrades/Upgrade Pfade mit statischen Scripten je Version. Nebenbei: Kannst Du sicherstellen, dass ein Istzustand nicht vom Nutzer verfremdet wurde? Migration: Hier wird ja klassisch am lebenden Objekt gearbeitet. (Oder gern auf einer Staging Kopie, ..) Als Alternative kann man auch überlegen, ein komplett neues System hochzuziehen. Das bietet sich vielleicht bei starker Restrukturierung an. Programmupdates, Neuerungen sind ja oft einfach Erweiterungen, gern abwärtskompatibel. Deine Beschreibung der Änderungen klingt aber etwas radikaler, daher ist es vielleicht hilfreich, nicht das Altsystem zu verändern, sondern neu aufsetzen und Altdaten rüberziehen. Das kann man notfalls solange machen, bis es funktioniert- ohne das Altsystem abzuschießen, es wäre damit jederzeit verfügbar, falls eine Migration fehlschlägt. :) Diese Variante hätte den Vorteil, dass das alte System weiterlaufen könnte / ausgeschlichen werden kann, wenn nötig. Notfalls könnte sogar live auf alt und neu gearbeitet werden. Das neue System hätte dann Views ins alte System. Aber das macht man natürlich nicht ohne Not. Ein ganz neues System aufzusetzen hat neben diversen Vorteilen allerdings den Nachteil, dass mindestens für den Migrationszeitraum / Parallelbetrieb die DB Ressourcen doppelt vorhanden sein müssen. (Was sie allerdings häufig sowieso sind in Form von Hot Standby usw. Systemen) Was ist es überhaupt für ein System? Lokale Anwendung (ala Musikdatenbank , .. ) oder eher eine Firmensoftware? |
AW: Datendefinition der DB im Programm prüfen
Zitat:
Zitat:
Zitat:
Die grundsätzlich DB-Struktur steht fest und wird sich auch nicht wesentlich verändern. Mit dieser Struktur läuft das Programm seit mehr als 12 Jahren. Es ist noch unter D7 geschrieben und beinhaltet einige Fremdkomponenten. Das, und die Tatsache, dass es über die Jahre an vielen Ecken "angestückelt" wurde, macht eine direkte Übernahme sehr Aufwendig. Auch sollen alle Fremdkomponenten durch eigene Komponenten ersetzt werden. Einzig ein paar Jedi-Komponenten, und die DB-Komponente sollen weiterhin Third-Party bleiben. Deswegen habe ich mich entschlossen, es von Grund auf neu zu schreiben. Die DB-Struktur soll aber im wesentlichen erhalten bleiben. Für die Neuentwicklung könnte ich die DB auch von Hand anlegen und jeweils erweitern. Und vor Auslieferung wird auch ein ausgiebiger Migrationstest stattfinden, so dass alle Daten aus der bisherigen Struktur übernommen werden können. Allerdings wird es auch nach Fertigstellung eine Weiterentwicklung geben. Und da geht es letztlich oft nur um Kleinigkeiten z.B: ein Datenfeld ist zu klein, ein Datentyp wird geändert, weil er sich so besser verarbeiten lässt, usw. Und natürlich wenn gänzlich neue Funktionen hinzukommen auch mal ein neue Tabelle. Das soll aber so geschehen, wie es auch bisher ist, dass der Kunde eben die neue Version herunterladen kann, und beim ersten Start die DB im Programm angepasst wird (solche Dinge wie Update nur wenn keine anderen Clients laufen, und Programmstart verhindern wenn DB-Update läuft, sind bereits berücksichtigt). So war es auch die letzt 12 Jahre und so sollte es auch im neuen Programm laufen. Das ein Kunde die DB-Struktur verändert kann ich nahezu ausschließen. Zwar nicht in letzter Konsequenz, aber wer mutwillig rumspielt und manipuliert hat halt Pech. Dafür gibt's ja Datensicherungen. Ich möchte nun den Aufwand für mich relativ gering halten und auch dafür sorgen, dass alle Vorgänge nahezu automatisch ablaufen. Aber es sind mittlerweile ca 70 Tabellen. Also kommt schon etwas zusammen. Ich muss mir das alles noch ein wenig durch den Kopf gehen lassen. |
AW: Datendefinition der DB im Programm prüfen
<Schrott geschrieben, hab Dich mit Codehunter verwechselt>
.. welcher Versionsstand beim Kunden vorliegt und folglich, welche Alterscripte alle laufen müssten. Da ist es dann schon spannend, nach einer -wie auch immer gearteten- Analyse, zu einem von n bekannten Ausgangszuständen zu kommen (Änderungen durch den Kunden selbst gibt es ja praktisch nicht). Wenn es als n Ausganszustände gibt und 1 Zielzustand gibt, gibt es n-1 Alterscripte, die haargenau festgelegt sind, oder? Wenn Du keine explizite Metainfo über die vorliegende Version gibt, reicht es evtl. anhand von Spaltenanalysen "Fingerabrücke" festzustellen, die den Stand wiedergeben. Man spart sich also eine mglw. unsaubere Analyse der DDL und Differenz Script Generierung und baut im Labor die notwendigen, definierten, festen Alterscripte. Dabei kann man dann noch überlegen, ob man (bei größeren Datenbewegungen) einige der Zwischenskripte zusammenfasst, um größere Sprünge in einem zu ermöglichen, also ganz alte Version in 2 Schritten auf aktuell, statt in 11 Schritten. Interessant finde ich hier bei Firebird, wie es mit impliziten Commits (durch DDL) aussieht. Das macht jedes System anders und wenn man nicht Acht gibt, ist -zumindest bei unvorhergesehenen Ausgangslagen- das Kind schnell in den Brunnen gefallen. |
AW: Datendefinition der DB im Programm prüfen
Bei uns ist das so gelöst + das klappt gut:
- Es gibt in der Software eine Konstante DB_VERSION, zB 12 - Es gibt weiter eine Klasse, die Änderungsscripts auf die DB loslassen kann. Die Änderungsscripts sind an eine DB-Version gebunden + vergleichen diese Version mit der Konstanten. So kann die Klasse erkennen, welche Scripts ausgeführt werden müssen und schreiben die DB Version in die Datenbank. An der Stelle können auch Datenänderungen durchgeführt werden, wenn nötig. Weil die Klasse zusätzlich auch eine Info in der DB ablegt, kann man sich dann versionsbezogen eine History ansehen. - Über die DB_VERSION kann der Client abgleichen, ob die DB-Version der DB mit seiner eigenen übereinstimmt. Wenn nicht --> Meldung bzw Ende. - In Multiuser-Umgebung funktioniert das auch - der erste Client updatet die DB, uns für die anderen passt es dann schon. - Bei der Auslieferung der Software stimmten die beiden DB Versionen natürlich überein + ab dann funktioniert obiges Schema. Aurelius hat einen automatischen Strukturabgleich, aber der ergänzt nur + löscht keine Felder bzw migriert Daten. Und: Wir haben da gleiche Schema auch für reine Datenänderungen ohne Strukturänderungen (zB Umkodieren etc). Alles, was nur 1x gemacht werden soll, kann so abgebildet werden. |
AW: Datendefinition der DB im Programm prüfen
Hallo,
Zitat:
und deshalb die DB-Version noch nicht hochgezählt hat. |
AW: Datendefinition der DB im Programm prüfen
Zitat:
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. |
AW: Datendefinition der DB im Programm prüfen
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Datendefinition der DB im Programm prüfen
@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. |
AW: Datendefinition der DB im Programm prüfen
@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. |
AW: Datendefinition der DB im Programm prüfen
Hallo.
Zitat:
Die Frage stelle ich, weil ich auch vor dem Problem stehe. Hast Du das Datenbank-neutral gelöst? |
AW: Datendefinition der DB im Programm prüfen
Zitat:
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). |
AW: Datendefinition der DB im Programm prüfen
@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. |
AW: Datendefinition der DB im Programm prüfen
Zitat:
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. |
AW: Datendefinition der DB im Programm prüfen
Zitat:
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. |
AW: Datendefinition der DB im Programm prüfen
@TigerLilly
Dann sind die DB-Zugangsdaten in der App hart verdrahtet oder liegen in einer Konfig-Datei? Also so wie da DB-Zugangsdaten verschlüsseln besprochen? |
AW: Datendefinition der DB im Programm prüfen
@Schokohase: Natürlich unverschlüsselt in einer Konfig-Datei. Nein, warte - fix verdrahtet per App. Dann müssen wir uns nur einen User merken für alle Kunden, das erleichtert den Support. :thumb:
Nein, im Ernst. Die Zugangsdaten sind natürlich verschlüsselt abgelegt, wahlweise INI oder registry. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 13:45 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz