SQL Script Prozessor für Entwicklung gesucht

[Frank (no reg)]

Hallo,

für die Neuentwicklung einer Datenbank möchte ich gern die Datenbank-
objekte einzeln in eigenen Scripts verwalten.

Da die Datenbankobjekte untereinander natürlich auch Beziehungen haben,
ein Foreign Key kann ja nicht ohne entsprechende Tabellen existieren,
und so weiter, und ich gern am Ende ein großes Script für die Komplett-
Installation herausbekommen möchte, suche ich eine Möglichkeit des
automatischen Verarbeitens der einzelnen Scripte durch Definition von
Keywords o.ä. für Abhängigkeiten.

Kennt jemand Tools mit denen man dies bewerkstelligen kann?

Danke für eure Hilfe,
Frank

[Ludger]

Hi,

für die Neuentwicklung einer Datenbank möchte ich gern die Datenbank-
objekte einzeln in eigenen Scripts verwalten.

Du meinst einzelne DDL-Scripts fuer einzelne Datenbankobjekte? Das geht.   :-)

Da die Datenbankobjekte untereinander natürlich auch Beziehungen haben,
ein Foreign Key kann ja nicht ohne entsprechende Tabellen existieren,
und so weiter, und ich gern am Ende ein großes Script für die Komplett-
Installation herausbekommen möchte, suche ich eine Möglichkeit des
automatischen Verarbeitens der einzelnen Scripte durch Definition von
Keywords o.ä. für Abhängigkeiten.

Du moechtest in einem bspw. von Dir erstellten GUI die Einstellungen der Datenbankobjekte aendern und automatisiert Aenderungen an den einzelnen Scripten erreichen? BTW - was meinst Du hier mit _Keywords_?

Kennt jemand Tools mit denen man dies bewerkstelligen kann?

SQLEM?   :-)
Nee, ich bin ehrlich, hab die Anforderung nicht ganz verstanden.

Gruss,
Ludger

[Frank (no reg)]

Hi Ludger,

Nee, ich bin ehrlich, hab die Anforderung nicht ganz verstanden.

Da scheinst du irgendwie nicht ganz der einzige zu sein..

Mit dem "DDL-Scripts" bist du schon mal nah dran, genau, ich möchte
einzelne Scripts für CREATE TABLE bis CREATE PROC usw schön jedes für
sich mit CVS/SVN entwickeln und verwalten, natürlich auch genauso
RDBMS-unabhängig (also egal ob für mySQL oder Oracle oder Yukon...).

Da habe ich aber zum einen das Problem, dass manch eine View oder
Funktion von anderen Funktionen, bestehenden Tabellen abhängig ist.
Dies möchte ich im Script dann eben durch Keywords à la

-- #DEFINE DEPENDENCY [sp_DELETE_BLABLABLA]

ausdrücken (Ich denke du kannst dir vorstellen was o.g. Statement
bedeuten soll). Die Scripts sollen natürlich auch einzeln problemlos
ausführbar sein. Darüber hinaus möchte ich auch anhand solcher
Keywords die Scripte in größere Sammelscripte zusammenfassen, z.b.

• 1x Komplett DB leer
• 1x Komplett DB mit Testdaten
• Nx Upgrade-Scripts

... natürlich dann in einer korrekten Reihenfolge der Datenbankobjekte

... Weil, so ca. 300 Scripts einzeln im Query Analyzer auszuführen,
könnte etwas lähmend werden.

Ich bin schon fast dran, mir sowas selbst zusammenzufrickeln, aber
vielleicht hast du ja eine Idee.

Grüße, schönen Sonntag noch, bis bald
Frank

[Ludger]

Hi,

Ich bin schon fast dran, mir sowas selbst zusammenzufrickeln, aber
vielleicht hast du ja eine Idee.

OK, ich habs verstanden. Ausgezeichnete Idee! Und dann auch noch RDBMS-unabhaengig.   :-)

Also denkbar und damit auch moeglich ist das natuerlich. Nehmen wir mal an, dass es eine Loesung fuer ein RDBMS gibt, nehmen wir einfach mal MSSQL Server 2000. Dann haetten wir was genau?

Wir editieren ein Script fuer die Tabelle1 und entfernen ein Datenfeld1, daraufhin werden abhaengige Scripte anhand des "Keywords" durchforstet und automatisiert Anpassungen vorgenommen. Bspw. werden foreign key Einstellungen entfernt und bestimmte stored procedures und views angepasst. Du merkst worauf ich hinaus will? Ich glaube, dass das was Du vorhast nur eingeschraenkt moeglich ist.

Vergleiche auch die "Abhaengigkeitsverwaltung" in MSSQL Server, das "funzt" auch nicht so recht, ich selbst habe da haeufig Inkonsistenzen in der "Abhaengigkeits-Datenbasis" festgestellt.

Aber halt uns auf dem Laufenden. Interessantes Thema. BTW - hast Du MSSQL Server mit dem VSS mal getestet, taugt das was oder ist das schnulli?

Gruss,
Ludger

[Frank (no reg)]

Hi,

na ganz so verstanden scheinst du es noch nicht zu haben. Es geht nicht
darum, dass dann automatisch Foreign Keys o.ä. entfernt werden, sondern
einfach nur um eine Verwaltung der einzelnen DDL Scripte, mit der man
auch Sammelscripte erzeugen kann (z.b. für Installationsprozeduren).
Wo die Inhalte dann in der richtigen Reihenfolge auch drin sind.

Mit VSS meinst du Visual Source Safe? Wenn ich einem Produkt aus dem
Hause MS definitiv nichts zutraue für die Praxis, dann ist das VSS6.
Es war dermaßen doof einzurichten für Serverbetrieb dass ich ganz
schnell wieder die Finger von gelassen hab. Alles was eingecheckt war,
war automatisch read-only. Mein Fazit: Unbrauchbar für die tägliche
Arbeit.

Ich habe aber vorhin schon was gefunden, was ich mir mal näher
anschauen muss: GNU M4 Pre-Processor. Was ich gelesen hab, trifft es
akkurat mein Anwendungsbedürfnis.

Also, bis später, man liest sich.
Frank

[Ludger]

Hi,

na ganz so verstanden scheinst du es noch nicht zu haben.

mag schon sein.

Es geht nicht
darum, dass dann automatisch Foreign Keys o.ä. entfernt werden, sondern
einfach nur um eine Verwaltung der einzelnen DDL Scripte, mit der man
auch Sammelscripte erzeugen kann (z.b. für Installationsprozeduren).
Wo die Inhalte dann in der richtigen Reihenfolge auch drin sind.

Dennoch, das kann doch nur unter ganz bestimmten Bedingungen gehen, stimmts?

Gruss,
Ludger

[Frank (no reg)]

Mahlzeit,

Dennoch, das kann doch nur unter ganz bestimmten Bedingungen gehen, stimmts?

Worauf willst du hinaus, ich kann dir nicht mehr folgen?

Ciao, Frank

[Ludger]

Hi,

Dennoch, das kann doch nur unter ganz bestimmten Bedingungen gehen, stimmts?

Worauf willst du hinaus, ich kann dir nicht mehr folgen?

wenn Du Code ("DDL-Scripte") in irgendeinem CVS verwalten willst, dann wird sich eine Loesung finden lassen (CVS ? :-).

Aber das eigentlich Interessante waren fuer mich die Abhaengigkeiten und deren Verwaltung. Da habe ich zwar verstanden, dass Du mit ůKeywordsů kommen willst, aber welche Funktionalitaeten Du da genau erwartest blieb zumindest mir ein bis jetzt wenig verborgen. Aber auf die angeforderten Funktionalitaeten kommts anm, oder? (Gehts um den Aufbau einer vollstaendigen Datenbasis per "Installationsscript" zu jedem Zeitpunkt aus einer von mehreren Personen bearbeiteten Datenhaltung heraus? Gehts auch um Daten oder nur ums Design (ich vermute zurzeit, dass es nur ums Datenmodell geht?!)? Welche Arten von Abhaengigkeiten sind zu verwalten? Wie sollen unterschiedlichë RDBMSe "gebunden" werden, ANSI SQL? ...)

Gruss,
Ludger

[Frank (no reg)]

Hallo nochmals,

ah ja. Vielleicht doch noch mal ausführlicher:

Nehmen wir an, wir bauen eine ganz simple Datenbank (à la Northwind),
da wird/soll es folgende Tabellen geben.

• Kunden
  1:n
• Bestellungen
  1:n
• BestellArtikel

Ich mache dann also drei Scripte:

  
-- script datei "Table_Create_Kunden.sql"  
CREATE TABLE [Kunden]  
(  
 [Id]  int   CONSTRAINT PK_kunden_id PRIMARY KEY CLUSTERED,  
 [Name]   varchar(255)  NOT NULL,  
 [eMail]  varchar(255) NOT NULL  
)  
  
  
-- script datei "Table_Create_Bestellungen.sql"  
CREATE TABLE [Bestellungen]  
(  
 [Id]   int   CONSTRAINT PK_bestellungen_id PRIMARY KEY CLUSTERED,  
 [Kunden_Ref]   int  NOT NULL,  
 [BestellDatum]   datetime  NOT NULL DEFAULT GETDATE(),  
 [LieferDatum]    datetime  ,  
 [RechnungDatum]  datetime  
)  
  
  
-- script datei "Table_Create_Bestellartikel.sql"  
CREATE TABLE [BestellArtikel]  
(  
 [Id]   int   CONSTRAINT PK_bestellartikel_id PRIMARY KEY CLUSTERED,  
        [Artikel_Ref]  int  NOT NULL,  
 [Bestellung_Ref] int  NOT NULL,  
 [Menge]     smallint  NOT NULL,  
 [EinzelNetto]    money   NOT NULL  
)  

Diese 3 Scripts kann ich noch einzeln in meinem SqlPlus oder QueryAnalyzer ausführen, allerdings setzen sie jetzt schon eine existierende Datenbank voraus, die irgendwann mal mit einem Statement à la:

  
-- script datei "Database_Create_Bestellsystem.sql"  
CREATE DATABASE [BestellSystem]  

Voriges ist natürlich sehr rudimentär und ich möchte dann vielleicht doch noch ein paar Einstellungen hinzufügen (Filegroups, was auch immer). Mit anderen Worten, es wird in einem eigenen Script verwaltet.

Was deinem wachsamen Auge sicher aufgefallen ist, es fehlen noch die FK Contraints. Auch die werden dann in Scripts für sich, mehr oder minder gesammelt nach Tabellen verwaltet. Ausgeführt auf der DB können diese natürlich erst werden, wenn die Tabellen schon da sind.

Was ich jetzt mit den Keywords erreichen will, ist dass alles entsprechend für notwendig deklarierte in einem einzigen größeren Script rauspurzelt:

  
-- Komplett-Script Anfang  
------------------------------------------------------  
CREATE DATABASE [BestellSystem]  
ON  
( NAME = Sales_dat,  
   FILENAME = 'c:\program files\microsoft sql server\mssql\data\saledat.mdf',  
   SIZE = 10,  
   MAXSIZE = 50,  
   FILEGROWTH = 5 )  
LOG ON  
( NAME = Archlog1,  
   FILENAME = 'c:\program files\microsoft sql server\mssql\data\archlog1.ldf',  
   SIZE = 100MB,  
   MAXSIZE = 200,  
   FILEGROWTH = 20)  
GO  
  
CREATE TABLE [Kunden] ( )  
GO  
  
CREATE TABLE [Bestellungen] ( )  
GO  
  
CREATE TABLE [BestellArtikel] ( )  
GO  
  
ALTER TABLE [Bestellungen] ADD CONSTRAINT FK_Bestellungen_Kunden FOREIGN KEY (Kunden_Ref) REFERENCES Kunden(Id)  
GO  
  
-- und so weiter ...  
------------------------------------------------------  
-- Komplett-Script ENDE  

Um das zu erreichen füge ich im Script für das Foreign Key Constraint einfach solch ein Schlüsselwort: (Beispiel)

-- #REQUIRE OBJECT [Bestellungen]
-- #REQUIRE OBJECT [Kunden]

Darüber hinaus könnte es noch ein weiteres Schlüsselwort geben, was angibt ob das Script überhaupt verwendet werden soll...

-- #INCLUDEIN OUTPUT [FULL]

Der Prozessor soll einfach nur die einzelnen Dateien aneinanderhängen, er braucht sich überhaupt nicht mit dem SQL Dialekt auskennen. Die Kondititionen für die einzelnen Scripts zu definieren ist Aufgabe des Entwicklers. Dem Prozessor ist auch egal, ob das SQL Script logisch oder syntaktisch korrekt ist. Desterwegen bleibt es ja RDBMS-unabhängig. :)

Auch das Einfügen von Daten (Basisdaten oder auch zusätzliche Testdaten) soll damit gesteuert werden.

Ich hoffe, mein Ansinnen ist dir nun etwas klarer geworden. :)

Grüße, Frank

[Ludger]

Hallo Frank,

Ich hoffe, mein Ansinnen ist dir nun etwas klarer geworden. :)

ich konnte nun nachvollziehen, was Du wuenschst. Du moechtest sowas wie eine Scripterstellung fuer einzelne DB-Objekte mit der Option "abhaengige Objekte ebenfalls erstellen" (und vermutlich einigen weiteren kleinen Features).

Dass man da eine ganze Menge machen kann, scheint klar, ein Produkt kann ich Dir da leider nicht empfehlen, obwohl ich ein wenig nachgefragt und recherchiert habe.

Ich ueberlege gerade warum ich sowas noch nicht gebraucht habe.   :-)

Gruss,
Ludger

[Vinzenz Mai]

Hallo

BTW - hast Du MSSQL Server mit dem VSS mal getestet, taugt das was oder ist das schnulli?

Wenn es sauber eingerichtet ist, taugt das was. War bei einem ehemaligen Arbeitgeber im Betrieb, damit ließ sich komfortabel arbeiten. Es hat _natürlich_ Konsequenzen für die gesamte Zusammenarbeit - und das ist gut so.

Freundliche Grüße

Vinzenz