Tabellenstruktur (MSSQL) bei Update überprüfen

[alzaimar]

Zitat von winnionkel:

@alzaimar
Ich denke nicht, das mein Datenbankdesign falsch ist. Ich habe jahrelang nichts anderes gemacht, als DBDesign.

Och, nur weil man lange etwas macht, heisst es ja nicht, das es der Weisheit letzter Schluss ist. Und Du sprichst ja selber davon, das Dein bisheriges Design zu einem Problem wird. Aber wenn Du damit klar kommst, ist doch fein. Wir machen das wie von mir beschrieben und müssen eben keine Tabellen updaten und/oder Versionskontrollen einbauen. Wenn der Kunde eine neue Spalte wünscht, kann er das erstens selber machen, oder die Anwendung fügt einfach eine Zeile in die 'Werte'-Tabelle ein.

Hast Du dann für jeden Kunden eine individuell angepasste EXE?

Zu Deiner Eingangsfrage: Wir verwenden SQL-Compare, ein Tool von Red-Gate. Das synchronisiert zwei DB-Schemas. Soweit ich weiss, besitzt das Tool auch eine API. Damit wäre es ein Kinderspiel, denn Du musst nur 'mal eben' eine zweite DB (mit der vollständigen Struktur) auf dem Ziel-Server erstellen, lässt das Sync-Tool darauf los und -wupps- ist die Kunden-DB auf dem neuesten Stand. Anschließend wird die Referenz-DB wieder gelöscht und fertig. Das geht auch bei komplexen DB recht flott.
Aber, und da hast Du ja Recht, kocht Redgate auch nur mit Wasser, produziert also nativen SQL-Code zum Synchronisieren. Und manchmal klappt das nicht, wenn man z.B. eine neue Spalte als 'NOT NULL' deklariert, aber kein Default-Wert angegeben wurde. Aber soetwas ließe sich ja im Vorfeld testen.

Also, ich weiss nicht. Mir ist da ein Redesign lieber, das die Tabellennamen in Views überführt, sodaß die Anwendung nichts mitbekommt, aber unter der Oberfläche mit dem Metadatenschema arbeitet. Na ja, Jedem das Seine.

[Phoenix]

Zitat von winnionkel:

Vielleicht habe ich mich falsch ausgedrückt. Der Kunde will vielleicht zwischendurch mal einige Änderungen am Prog. Ich muß dafür in einer Tabelle zwei Felder anlegen.
Ich schicke dem Kunden die neue exe. Beim Start muß diese dann sehen, ob diese Felder da sind, eventuell anlegen. Der nächste Kunde möchte aber noch gaaaanz lange mit dem alten Prog arbeiten.

Ja. Und? Ist doch abgedeckt. Kunde B bekommt die neue .exe halt nicht.
Wenn der Kunde B dann gegen später irgendwann mal updated gibts halt n Zwischenversionen über die seine neue .exe dann halt updatet. Stört doch nicht.

Aber ich würde mir dennoch mal Gedanken über das Design machen. Das scheint bei Dir nicht so ganz Konsistent zu sein. Änderungen am ERD sollten - wenn überhaupt - nur extrem nötig sein. Sonst bedeutet das einfach, dass ins ursprüngliche Konzept nicht genug Hirnschmalz gesteckt wurde und ein komplettes Redesign was auch zukünftige Änderungen/Erweiterungen abdeckt nötig ist.

Die alte/bisherige Struktur kann dann immer noch über Views abgedeckt werden, so dass keine oder nur minimale Codeänderungen nötig sind.

[winnionkel]

Ich muß euch allen Recht geben. Auch habt Ihr mich auf eine Idee gebracht.
Mein Grundmodul bleibt ja immer gleich. ( Außer Fehlerbereinigung ).
Ich werde dann individuelle Kundenmodule entwickeln, die dann in der DB nur die für
dieses Modul notwendigen Tabellen anlegt.
Somit brauche ich bei einem Update des Kundenmoduls nur diese Tabellen überprüfen.
Die Haupt DB bleibt dann unberührt.