Datenbank zur Laufzeit anlegen usw. ??

[Hansa]

Hi,

die letzte Zeit tauchen überall vermehrt Fragen dazu auf, wie zur Laufzeit eine Datenbank, Tabellen, sogar einzelne Felder usw. erstellt werden können. Hauptsächlich im MySql - Umfeld. Mich beschäftigt hierbei die Frage, wie ein bestehendes (und fertiges !) Programm mit so etwas umgehen soll.

Also : wer macht / braucht sowas, wozu und warum überhaupt ? IMHO sollte man einen Enduser nicht an der DB rumfummeln lassen. Offensichtlich wird das aber trotzdem gemacht. Die Hauptfrage geht darum, wie so etwas im eigenen Programm berücksichtigt wird. Insbesondere, wie das Anwendungsprogramm vorher nicht mal bekannte Felder überhaupt behandelt.

[s-off]

Hallo,

Zitat:

[...]wie ein bestehendes (und fertiges !) Programm mit so etwas umgehen soll.

Naja, 'fertig' ist so ein Begriff ^^

Ich nenne Dir mal ein Beispiel:
Der Kunde stellt Requirements, die eine Erweiterung der Datenbankstruktur erfordern - ein Klassiker.
Der Endnutzer macht das natürlich nicht selber, aber da man nicht jeden besuchen möchte, erstellt man Packages, die das für einen machen.

[Jelly]

Irgendwie muss die Datenbank ja auf dem Zielsystem eingerichtet werden. Ob das durch blankes Kopieren einer Firebird Datei passiert, oder durch Anlegen der Datenbank per SQL ist imho irrelevant. Grad bei Firebird klappt dieses Kopieren ja auch, aber bei anderen Datenbanksystem halt nicht (mit gutem Grund), wie z.B. MSSQL. Also bleibt nix Anderes übrig als die Datenbank zu erstellen.

Du willst den Enduser nicht an der Datenbank rumfummeln lassen. Das ist ok. Aber schwer praktikabel, denn die DB MUSS ja angelegt werden. In Firmen mag das ein DB Admin sein, aber privat macht das jeder selber, und das muss auf beim DAU ohne Aufwand funktionieren, denn nicht jeder Heimanwender hat einen Experten zur Seite, um eine Kochbuchsammlung zu installieren, die zufällig in einer MySQL Datenbank gespeichert wird.

Und noch ein sehr wichtiger Aspekt: Updates der Programme. Zumindest bei mir werden bei neuen Version auch ganz oft Änderungen an der DB Struktur vorgenommen. Und diese müssen auch beim Update ganz transparent in die DB eingepflegt werden. Und das geht eh nur noch über den Weg eines SQL Skriptes.

[Hansa]

Uff, die Nachtschicht ist noch schwer aktiv. Aber die Frage ist nicht, eine Datenbank anzulegen. Das muß irgendwer irgendwann sowieso machen. Die Frage nach den DAUs bleibt in dem Zusammenhang aber auch bestehen, ob die tatsächlich zu so etwas herausgefordert werden müssen. 8) Aber es dreht sich darum, ein Programm zu schreiben, das zum Zeitpunkt der Erstellung Kenntnis hat, von dann nicht existierenden Feldern, bzw. wofür das nötig ist. Da bitte ich um Aufklärung weshalb.

P.S.: Bevor das Thema jetzt schon in Schieflage gerät : es geht darum, das mit einem Delphi-Programm für eigenes Programm zu machen ! Daß die DB eventuell mal geändert werden muß ist klar.

[Jelly]

Lade dir mal mein Rema runter, da handhabe ich das wie folgt. Es gibt eine Tabelle mit der aktuellen Datenbankversion drin, ja sogar eine ganze History. Die sieht bei mir z.B. so aus:

Code:

# Query:
# SELECT *
# FROM `rm_remaversion`
# 
'ID','Datum','Major','Minor','Release','Build','Runned'
'4','2004-08-28 23:27:53','1','0','12','33','1'
'6','2004-09-20 00:10:27','1','0','13','34','1'
'7','2004-10-10 20:14:28','1','0','14','35','1'
'8','2004-10-20 19:59:40','1','0','16','37','1'
'9','2004-10-25 02:34:00','1','0','18','39','1'
'10','2004-11-04 15:33:30','1','1','2','40','1'
'11','2004-11-07 22:17:54','1','1','3','41','1'
'12','2004-12-11 20:13:50','1','1','4','43','1'
'13','2005-04-27 12:39:48','1','1','5','44','1'
'14','2005-05-17 09:34:27','1','1','4','42','1'
'15','2005-07-29 10:29:37','1','2','1','45','1'
'16','2005-12-14 23:13:55','1','2','4','51','1'

Das ist eine Liste von Datenbankupdateskripten, die bereits in der Datenbank vom Programm durchgeführt wurden, erkennbar an der letzten Spalte.

Vertreibe ich nun eine neue Programmversion (1.2.5.52), so lege ich meinem Program im Installationsverzeichnis eine Datei v.1.2.5.52.txt bei, die das DB Updateskript beinhaltet. Beim Start des Programms wird im Skriptverzeichnis nach neuen Einträgen gesucht, und diese in der Tabelle gepflegt, nur mit 0 in der letzten Spalte. Nach Einfügen der Datensätze führe ich dann vom Programm aus all diejenigen Skripte aus, die noch nicht ausgeführt wurde (0) bis zu der eigenen Programmversion, und natüclich in der richtigen Reihenfolge.

2 Sachen sind da imminent wichtig: erstmal nur die Skripte auszuführen, die für die eigene Programmversion relevant sind. Wenn ich noch Version 1.2.1.45 nutze, so brauche ich kein Update durchzuführen, auch wenn sich aus irgendeinem unerklärlichen Grund eine rezentere Updatedatei in mein Verzeichnis verirrt haben sollte. Man darf ja nie vergessen, dass mehrere Platzrechner in der Regel auf ein und dieselbe Datenbank zugreifen.

Willst Du nun diese Updates nicht von jedem Platz aus durchführen, dann kannst du dir ja auch ein kleines Tool schreiben, welches das dann zentral irgendwo abarbeitet.

[oldmax]

Hi

Eine Antwort auf eure Frage, "Warum zur Laufzeit..."
gebe ich folgende Aufgabe:

Eine Lagerverwaltung für ... (ich weiß nicht was, aber der Anwender baut ein xbeliebiges Regal in welches er xbeliebige Artikel legt. Diese möchte er nun gern an den PC's x,y und z abfragen. Er will auch wissen, wer hat die Bewegung im Lager gebucht und er will auch Einfluß auf die Zugriffsrechte haben. Und da ein Artikel wandert, vom Hersteller bis zum Kunden, will er wissen, wo ist mein gutes Stück gerade. Ihr habt also keine Ahnung, was euer "DAU" wirklich will. Vielleicht ist sogar eine Maschine im Lager, die Ein- bzw Auslageraufträge übernimmt, keine Ahnung. Nun, mich würde es interessieren, wie ihr nun ein solches Programm (Projekt) angeht.

PS: Ich hab's (fast) fertig in der Schublade liegen. Mit Historie, Bewegung, mit Limit Min und Max Überwachung, mit freien Referenztabellen für Lieferanten und Kunden, ach was weiß ich, was dem User noch so alles einfällt....

Als ich die ersten Tests gemacht hab, war ich erstaunt, was sich damit so alles abdecken ließe. Aber für jeden Datenbankprofi ist's wohl der reine Horror..... ( denn, normal is das nich )

Auf eure Antworten bin ich gespannt.... (ich würd's gern vermarkten, nur hab ich leider niemand, der's mit mit betreuen kann.....)

Martin

[eddy]

Hallo Hansa,

ich habe zu Paradox-Zeiten alle benötigten Datenbank- und Indexstrukturen in zwei Standard-DB gelegt, habe das Verfahren nach ADS übernommen und unter MySQL sollte es auch funktionieren.

Beim Start des Programms prüfe ich die Existens der erforderlichen Dateien ab, sollten eine Datei fehlen, wird diese mit der vordefinierten Struktur angelegt und der Index generiert. Ein paar Standard-DB (Vornamen, Plz-Ort, Steuersätze, usw.) werden, falls in einem bestimmten Verzeichnis vorhanden, aber auch nur kopiert.

Falls nun aus irgendeinem Grund eine Änderung in der Struktur einer vorhandenen DB erforderlich ist, wird die notwendige Ergänzung in der Definitionsdatei für Struktur und Index hinterlegt. Meist gibt's noch ein Programm-Update, weil ja das neue Feld auch irgendwie vom Programm angesprochen werden soll.

Der Anwender holt sich das Update, startet das Programm mit dem Parameter REORG und schon werden die Strukturen der vorhandenen Dateien geprüft, nötigenfalls ergänzt und die Index-Dateien neu aufgebaut. Der Programmstart dauert ein Mal etwas länger, das war's. Kein Stress mit nicht funktionierenden DB-Strukturen, fehlenden Feldern oder manueller Korrektur.

Anwender haben nichts an der Struktur der DB zu verändern, wenn die möglichen Freifelder nicht mehr reichen, muß eben das Programm ergänzt werden. Theoretisch könnte man es zwar soweit treiben, daß selbst dem Programmierer unbekannte Felder vom Programm angezeigt und verarbeitet werden, aber solche Anforderungen hat bisher noch kein Anwender gestellt.

mfg
eddy

[eddy]

Hallo oldmax,

irgendwie kann ich Dir nicht ganz zustimmen, ich weiß schon sehr genau, was meine Anwender wollen. Meistens können die Anwender nur nicht präzise formulieren, was sie wollen.

Lagerbewegungen zu verfolgen ist unkompliziert, aber selbst bei automatisierten Betrieben gibt es für die Datenerfassung noch Menschen, die irgendetwas eingeben und zuordnen müssen. Klappt der Wareneingang, ist es eigentlich gar kein Problem, alle Artikel vom Eingang bis zum Abgang an den Endkunden zu verfolgen (einschließlich Serien-Nummer jedes einzelnen Teiles).

Und Listen, von denen ich nicht weiß, ob sie ein Kunde benötigt, werden nicht definiert. Wer was benötigt, das im Programm noch nicht enthalten ist, meldet sich für gewöhnlich.

mfg
eddy