Einfach eine Tabelle in der Datenbank anlegen, die die
SQL-Statements enthält. Jedes Statement bekommt 'ne ID, 'ne Beschreibung und natürlich das eigentliche
SQL.
Damit verlagerst du aber einen Teil der Programmquellen (denn das sind
SQL-Statements) in die Datenbank des Users. Vom Standpunkt einer konsistenten Versionsverwaltung ist das eher kritisch zu betrachten. Was würde denn passieren, wenn der User eine alte Datensicherung wieder einspielt? Das müsste das Programm erkennen und die
SQL-Statements erstmal alle auf den passenden Stand bringen. Das gilt übrigens auch für das Einspielen einer älteren Programmversion. Das mag alles unter bestimmten Voraussetzungen funktionieren, aber ist es das wert?
Also dort, wo ich das für Kunden angewendet habe, gab es eine klare Trennung der Benutzerdaten und der Systemdaten. An den Systemdaten hat der User nichts zu suchen, das wurde ggfls. durch entsprechende Rechte geregelt. Bei Oracle z. B. ein eigenes Datenbankschema.
Benötigte der Kunde die Software für mehrere Mandanten, dann gab es das Systemschema mit eben dieser Tabelle und weiteren global gültigen Konfigurationsdaten und für jeden Mandanten ein eigenes Datenbankschema mit den Daten des Mandanten und ggfls. Konfigurationsdaten für diesen Mandanten.
Die Befüllung dieser Tabelle erfolgte immer aus den Datenbankscripten (mit denen auch die gesamte Tabellenstrukturen, Datenbankpackages ... - also als Teil des Datenmodells) ausgeliefert wurden. Und die wurden selbstverständlich mit in der Versionsverwaltung vorgehalten.
Zitat von
himitsu:
Gut, wir haben "viele" SQLs auch in der
DB, aber das ist eine synchronisierte Tabelle, wo man teilweise versionsabhängig aus einer/mehreren zentralen Synchro-Datenbank die aktuellen/passenden Daten runterladen kann/tut.
Vorallem ist es so möglich, dass man dort auch kundenspezifische Änderungen vornehmen kann.
Im Prinzip halte ich das ähnlich. Auch wenn es technisch möglich ist, dass der User selbst daran "rumbastelt", wir haben das eigentlich immer so gehandhabt, dass individuelle Änderungen von der Administration eingepflegt wurden oder eben (der Normalfall) von uns so ausgeliefert wurden.
Einfach nur mal so eben rumbasteln darf ich nur bei der Software, die ich für mich selbst schreibe und die ich mir dann selbst zerschieße.
Habe da mal 'ne Software geschrieben, die musste gegen dBase,
MSSQL, Interbase und Oracle laufen. Auf diese Weise habe ich im Programm nur das Statement für das Auslesen der Statements gehabt. Das kann man so einfach halten, dass es gegen alle Datenbanken läuft. Die übrigen Statements wurden entsprechend den unterschiedlichen Datenbanken syntaktisch angepasst und der Kunde hat die für "seine" Datenbank erforderliche Version ausgeliefert bekommen. Aber alle Kunden haben das gleiche Programm bekommen, da dort keine Anpassungen erforderlich waren.