Tabellenstruktur (MSSQL) bei Update überprüfen

[winnionkel]

Hallo,
ich suche eine Möglichkeit, bei einem Update meiner CallCenter Software, die Tabellenstruktur auf dem Anwendungsserver zu prüfen.
Im Moment mache ich es so, das in einer ini Datei die Tabellen und die Spaltennamen stehen.
Ich gehe zuerst die Tabellen durch. Wenn eine Tabelle nicht existiert, rufe ich aus einer text Datei den entsprechenden SQL String auf und erzeuge die. Dann gehe ich durch alle Felder und wenn nicht da, dann füge ich die an.
Im Moment hat mein Prog 25 Tabellen. Da geht es noch mit der Geschwindigkeit. Aber wenn das Prog größer wird, glaube ich habe ich ein Problem.
Das zweite Problem dabei ist, das meine Kunden keinen Datenbankadmin haben - das Update also in der Mittagspause der Agents laufen lassen müßen.

Hat vielleicht einer eine Idee ? Kann der SQL Server das vielleicht nicht auch schon von sich aus ?

Gruß Winni

[Phoenix]

Also der SQL Server hat unter Garantie eine Tabelle, in der die Tabellenstruktur selber steht. Oracle hat sowas, ADS hat das, ich kann mir nicht vorstellen dass der SQL Server sowas nicht hat.

Normalerweise kannst Du auf diese Tabellen auch eine View legen um das direkt per SQL abfragen.

[winnionkel]

Hallo Phonix,

die Tabellen und Felder auszulesen ist ja auch kein Problem:

ADOConnection.GetTableNames( StringList);
ADOConnection.GetFieldNames(Table, Stringlist);

Gehe dann durch alle Tabellen und Felder durch, und wenn die nicht vorhanden sind, werden die erzeugt.

Ich hatte so in der Art gedacht, ob der SQL Server das anhand einer Deffinitionsdatei, eventuell allein machen könnte.

[alzaimar]

Selbstverständlich hat der SQL-Server das, schließlich ist es Bestandteil der SQL-Definition. Die Tabellen heißen sysobjects und syscolumns.

Allerdings verstehe ich nicht ganz, wieso Du prüfen musst, ob die Tabelle auch alle nötigen Spalten hat. Das würde mich interessieren.

[Phoenix]

Zitat:

Zitat von winnionkel

Ich hatte so in der Art gedacht, ob der SQL Server das anhand einer Deffinitionsdatei, eventuell allein machen könnte.

Huh. Soweit ich weiss kann DAS kein DBMS.

Was die Performance angeht: Selbst mit Tabellen im GB-Bereich ist sowas kein Problem. Vor allem die Systemtabellen zum Abgleich sind, da IMMER gecached, superschnell abgefragt. Und es reicht ja, die einmal in eine Memtable zu laden und dort dann auf fehlende Fehler zu vergleichen.

Aber mal ne ganz andere Frage: Warum so kompliziert?

Vorschlag:
Wenn Du sowas wie eine Konfigurationstabelle hast hier einen Wert 'DBVersion' anlegen. Wenn Du keine Konfigtabelle hast, diese Anlegen und diesen Wert anlegen.

Eine Version des Datenbanklayouts bekommt ab dann immer eine definierte Version, die in dieser Konfig abgelegt wird.

Änderst Du Deine Tabellen, erhöhst Du die Datenbankversion. Die nötigen Scripte zum ändern (ALTER TABLE..., zur not mit Umweg über temp-tabelle wenns gröbere Änderungen sind etc.) lieferst Du immer alle mit dem Client aus - entsprechend der alten(!) Datenbankversion benamst. Letztes Statement ist freilich das updaten des DBVersion-Wertes auf die neue DB-Version.

Jeder Client benötigt dann einfach eine bestimmte Datenbankversion, die einfach aus dem DBVersion ausgelesen werden kann.

Zum Start des Client überprüft dieser die Version. Ist diese gleich der benötigten ist alles okay. Ist diese kleiner, wird das vorliegende Script zur aktuell eingetragenen DBVersion ausgeführt und danach der Wert nochmal abgefragt. Ist er immer noch kleiner wird das nächste Skript ausgeführt... bis die DBVersion am schluss mit der richtigen vom Client verlangten Version übereinstimmt.

Somit hast Du die Datenbank inkrementell immer auf dem aktuellsten Stand (selbst wenn ein Kunde mal 2 Versionen aussetzt bekommt er alle updates) und das läuft mit der Auslieferung einer neuen Clientversion auch vollautomatisch ab.

Wichtig ist nur, dass dann nicht zwei Clients gleichzeitig versuchen, upzudaten. Also müsstest Du den DBversion-Eintrag halt explizit vom ersten Client aus locken. Wenn schon gelockt ist kann der nächste Client keinen Lock bekommen und mnacht kein update sondern wartet bis der Lock wieder weg ist.

[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. Eines Tages hat er Geld und will dann die ganz neue Version. Dann müßen alle Felder, die ich in der Zwischenzeit eingebaut habe, erzeugt werden.

[mkinzler]

Du kannst doch trotzdem jede Änderung an der Datenbankstruktur durch Erhöhung der Datenbankversion protokollieren. Dann brauchst du beim Update nicht die Struktur der Datenbank auslesen sondern kannst anhand der Version feststellen, welche Änderungen notwendig sind.

[alzaimar]

@willionkel: Dein Datenbankdesign ist falsch. Wenn Du Änderungen bzw. Erweiterungen an deiner Datenstruktur als individuelle Anpassung an einzelne Kundenimplementierungen vorsiehst, solltest Du diese Datenstruktur als Bestandteil deines DB-Schemas implementieren ('Metadaten').

Anstatt z.B. eine Tabelle 'Daten' immer individuell zu erweitern, kannst du auch zwei Tabellen definieren, die "Daten"-Tabelle enthält nur die Daten-ID, sowie eventuell irgendwelche Werte, die imanent für diese Tabelle sind (Schlüsselnummer, Name etc.). In einer zweiten Tabelle definierst Du für jeden Datenwert (mit einer bestimmten Daten-ID) weitere Werte. So kannst Du dann für jede Implementierung individuell den Inhalt der zweiten Tabelle "Datenwerte" erweitern, ohne die eigentliche Struktur zu verändern.

Beispiel:
Klassisches Design: Eine Tabelle 'Daten' mit 3 Spalten: ID, Name, Anschrift
Metadaten Design: Zwei Tabellen:
1. 'Daten' mit einer Spalte 'Daten-ID'
2. 'Datenwerte' mit drei Spalten: 'Daten-ID','Wert-ID','Wert'

Über eine für jede Implementierung individuelle View hat hast Du dann die lokale Sicht auf die 'Datentabelle', die es in der Form ja gar nicht gibt. Als I-Tüpfelchen kannst Du im MS-SQL-Server dieser View auch noch beibringen, auf Änderungen (Insert, Update, Delete) so zu reagieren, das die Manipulationen am Datenbestand in den eigentlichen Tabellen 'Daten' und 'Datenwerte' vorgenommen wird. Das Zauberwort hier heisst "Updateable View" und "Instead Of Trigger" (oh, sind ja zwei Zauberwörter).

[winnionkel]

@mkinzler

Die Datenbankversion kann ich nicht einfach so ändern, da einige Kunden auch mit anderen Programmen auf meine DB zugreifen. Oder aber ich greife auf eine vorhandene DB des Kunden zu.

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

Ich weiß auch nicht, aber irgendwie möchtet ihr das alle so kompliziert.
Wenn man im Managment Studio einer Tabelle neue Felder einfügt, dann macht der genau das selbe, wie wir das vor zehn Jahren gemacht haben.

Alte Tabelle umbennen. Neue Tabelle erstellen. Daten von alter Tabelle nach neuer kopieren. Alte Tabelle löschen. Das ist jetzt kein Witz.


Ich hoffe mir ist keiner böse.

[mkinzler]

Zitat:

@mkinzler

Die Datenbankversion kann ich nicht einfach so ändern, da einige Kunden auch mit anderen Programmen auf meine DB zugreifen. Oder aber ich greife auf eine vorhandene DB des Kunden zu.

Warum nicht? Diese Versionsnummer ist ja nur eine Eintrag in eine Tabelle.

[alzaimar]

Zitat:

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? :shock:

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:

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.