DDL-Funktionalitäten in Delphi-Programmen fest verdrahten?

[p80286]

Immer wieder tauchen hier Beiträge auf, in denen Datenbanken angelegt werden, Tabellen modifiziert werden, kurz Aufgaben eines DB-Administrators in einem Programm vergossen werden. Das setzt mindestens einen entsprechenden Host und die notwendige Berechtigung vorraus. Die notwendigen Prüfungen beschränken sich aber meist auf wenns geht ist gut, wenn nicht "woher kommt denn dieser Fehler"??
Dieses Vorgehen mag für einige lokalen Datenbanken für Spielstände hinreichend sein, für "richtige" Datenbanken auf einem Server der/die u.U. extern administriert wird/werden verbietet sich dies meiner Meinung nach.
1) Ein DBadmin der irgendeine Exe laufen läßt, die seine Datenbank modifizieren soll, sollte sich gleich nach einem neuen Arbeitgeber umsehen.
2)Einer EXE sieht man auf den ersten Blick nicht an was in ihr steckt. In den meisten Fällen sollte es vollkommen ausreichend sein, ein Script zur Verfügung zu stellen, dann kann auch der DB-Admin sich ein Bild machen und man kann ggf. darüber Diskutieren ob zB. die Indices sinnvoll sind.
2a) Da ein Script relativ offensichtlich preisgibt was es leistet, ist es auch oft leichter zu überprüfen ob das Script zur aktuellen DB passt. In einer Exe verpackt ist das dann ein Blindflug wo man darauf vertrauen muß das wirklich die korrekte Befehle verwendet wurden.

Unterm Strich ich halte es nicht nur für Überflüssig wenn DataDefinition-Funktionalitäten in Programmen auftauchen, es ist auch fehleranfällig und nur aufwendig zu pflegen.

Liege ich mit diesen Ansichten vollkommen falsch oder was meint Ihr?

Gruß
K-H

[Uwe Raabe]

Es gibt genügend Fälle, bei denen vor Ort gar kein DB-Admin vorhanden ist.

Die einzige Aktion, die der Kunde ausführen muss, ist dann das Update anzustoßen. Gegebenenfalls wird überprüft und darauf hingewiesen, daß andere Benutzer das Programm beenden müssen um die Datenbank freizugeben, wobei auch das programmtechnisch unterstützt wird. Der Rest läuft dann automatisch.

Es wäre auch nicht hinnehmbar, bei Tausenden von Kunden den jeweiligen DB-Admin (der wie gesagt in der Regel eh nicht existiert) damit zu beauftragen, ja sogar auf ihn angewiesen zu sein.

Die wenigsten meiner Kunden wären in der Lage, eine solche Aufgabe durchzuführen.

[HolgerX]

Hmm..

Und eigentlich ist der Anwendungs-Entwickler der DBAdmin, da er die entsprechenden Tabellen und Indexe für die Funktion seiner Applikation benötigt.
Wie soll ein Kunden-DBAdmin, welcher die eigentliche Anwendung gar nicht kennt, entscheiden können, welche Tabellen wie angelegt werden?

Die Kunden-DBAdmins, welche ich kenne, legen den DB-Server an, richten die User (eventuell) ein, spielen die Updates der Engine ein und konfigurieren die Backups.
Was jedoch in den Datenbanken wie vorhanden ist, dass wollen die gar nicht wissen, denn bei diversen Applikationen mit zich Datenbanken haben sie gar keine Zeit sich um deren internen Aufbau zu kümmern.

Teilweise ist dieser Aufbau sogar per Vertrag als Betriebsgeheimnis des Anwendungsentwicklers eingestuft...

Der DB Admin, oder besser 'Systemadministrator' des Kunden kümmert sich eigentlich nur um folgende Punkte:
- Aufsetzen des Datenbank-Servers
- Einspielen der Updates der Datenbank-Engine
- Erstellen und Sichern von Backups

Mit diesen Admins haben wir beim Kunden nur bei der Erstinstallation und dann nur wenn die Datenbank auf eine neue Version der Engine umgestellt werden muss zu tun.

[Neumann]

Also wir haben etliche Kunden, die unser Programm mit Datenbank einsetzen, die nicht mal wissen was ein Explorer ist oder was die Tastenkombination Alt-F4 bedeutet usw.

Auch Datensicherung ist oft völlig unbekannt.

Wie sollen diese Leute entscheiden welcher Index in der Datenbank sinnvoll ist?

Dies bitte nicht falsch verstehen, ich möchte niemanden abwerten, weil keine PC-Kenntnisse vorhanden sind. Jeder hat seine Stärken und Schwächen.

Bei uns macht allein das Programm selber Änderungen an der Datenbank beim Kunden, und das werde ich auch beibehalten.

[TigerLilly]

Ha, gutes Thema. Unser Programm führt Änderungen an der DB selbsttätig aus, da muss der User gar nichts machen. Über eine Versionierung ist das sehr elegant gelöst und hat immer wunderbar funktioniert.

Dann kam ein großer Kuden + hat geasgt, das kommt nuicht in Frage, da weiß ich ja nicht, was die App in der DB so macht. Ich wär ja der meinung gewesen, dass die App in ihrer eigenen DB machen soll, was sie will, sie kann ja - bei einem gscheit administrierten System eh nicht raus - eh nicht raus.

Aber großer Kunde ist Kunde, der anschafft.

Also haben wir den Teil, der die versionierung macht, so umgebaut, dass die Änderungen in ein Script gespeichert werden, das schaut sich der Admin an, fühgrt es aus + die App kann mit dem neuen Versionsstand weiterlaufen. So braucht die APP auf der DB keine DBO Rechte, das ist eh recht cool. TRIGGER disablen geht zum Glück mit ein bissl tricksen auch anders.

Wirklich verstehen tu ich diesen Wunsch nicht, weil die bösen Sachen ja eher mit Daten manipulieren zu tun haben, aber DB Admins sind da wohl eigen.