@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).