[SQL Server 2000] CREATE TABLE stment genereren

[whoami]

Ik ben bezig met een simpel programmatje waarmee ik de database die door ons project gebruikt wordt, kan laten genereren.
Dit programma doet eigenlijk niets anders dan de DDL bestanden die nodig zijn gaan uitvoeren dmv isql.

Nu heb ik ook -zoals in een ander topic reeds vermeld- nood aan history tables. Die history-tables komen in dezelfde databank maar op een andere filegroup.
Ik wil die history tables laten 'genereren'; dwz, voor iedere 'data-tabel' wil ik een history tabel laten genereren.
Nu moet die history tabel (vrijwel) identiek zijn aan de 'data-tabel'. Ik weet dat ik dmv de sp_columns stored procedure de column-informatie van een bepaalde tabel kan ophalen. Adhv die gegevens kan ik idd de 'CREATE TABLE' genereren, maar ik zit nog met een probleem:

Zoals je weet, moet je bij bepaalde columns een lengte aangeven (bij VARCHAR bv), en bij andere mag je dat dan weer niet doen (INT).
Een bijkomend probleem is ook de 'decimal' datat-types. Hier moet je niet alleen een lengte, maar ook een precisie aangeven.
Nu is mijn probleem: hoe kan ik te weten komen bij welke columns ik de lengte van het datatype moet specifieren, bij welke niet, en bij welke ik een scale / precision moet aangeven?

Ik heb ook al gezien dat er een makkelijkere manier bestaat om een tabel te maken met een identieke tabelstructuur; ik kan hetzelfde bekomen dmv een SELECT INTO .. FROM statement, maar daar heb ik geen controle over de FILEGROUP waar die tabel moet komen...

[P_de_B]

Kun je het niet in een paar stappen verdelen?

Eerst SELECT INTO voor de correcte layout, dan een ALTER TABLE voor het eventueel wijzigen van de filegroup en ten slotte het toevoegen van de constraints en indexen (die worden niet overgenomen met een SELECT INTO)

[whoami]

P_de_B schreef op donderdag 16 december 2004 @ 09:41:
Kun je het niet in een paar stappen verdelen?

Eerst SELECT INTO voor de correcte layout, dan een ALTER TABLE voor het eventueel wijzigen van de filegroup en ten slotte het toevoegen van de constraints en indexen (die worden niet overgenomen met een SELECT INTO)

Daar had ik idd ook al aan gedacht, maar blijkbaar kan je met een ALTER TABLE statement de filegroup niet wijzigen....
In de BOL vind ik enkel hoe je een tabel naar een andere filegroup kunt plaatsen dmv de Enterprise Mgr.

Dit brengt mij echter wel op het idee dat ik eens kan kijken met de Profiler wat de Enterprise Mgr doorstuurt naar Sql Server om die tabel naar een andere filegroup te plaatsen...

[P_de_B]

Hmm, hier staat wel wat intressante info: http://www.sqljunkies.com...25-9246-6143A8681900.scuk

[justmental]

Ik heb wel een voorbeeldje voor je, maar dan in Oracle PL/SQL.
Als alternatief kun je misschien denken aan een 'create table as select' statement, of heeft SQL server dat niet?

[whoami]

justmental schreef op donderdag 16 december 2004 @ 09:48:
Ik heb wel een voorbeeldje voor je, maar dan in Oracle PL/SQL.
Als alternatief kun je misschien denken aan een 'create table as select' statement, of heeft SQL server dat niet?

Ik heb daar alleszins nog niets over gelezen, ik kan wel eens eea opzoeken...

Ik heb nu ook dit gevonden dat ik eerst eens ga lezen:
klik

[P_de_B]

code:

CREATE TABLE 
    [ database_name.[ owner ] . | owner. ] table_name 
    ( { < column_definition > 
        | column_name AS computed_column_expression 
        | < table_constraint > ::= [ CONSTRAINT constraint_name ] }

            | [ { PRIMARY KEY | UNIQUE } [ ,...n ] 
    ) 

[ ON { filegroup | DEFAULT } ] 
[ TEXTIMAGE_ON { filegroup | DEFAULT } ] 

< column_definition > ::= { column_name data_type } 
    [ COLLATE < collation_name > ] 
    [ [ DEFAULT constant_expression ] 
        | [ IDENTITY [ ( seed , increment ) [ NOT FOR REPLICATION ] ] ]
    ] 
    [ ROWGUIDCOL] 
    [ < column_constraint > ] [ ...n ] 

< column_constraint > ::= [ CONSTRAINT constraint_name ] 
    { [ NULL | NOT NULL ] 
        | [ { PRIMARY KEY | UNIQUE } 
            [ CLUSTERED | NONCLUSTERED ] 
            [ WITH FILLFACTOR = fillfactor ] 
            [ON {filegroup | DEFAULT} ] ] 
        ] 
        | [ [ FOREIGN KEY ] 
            REFERENCES ref_table [ ( ref_column ) ] 
            [ ON DELETE { CASCADE | NO ACTION } ] 
            [ ON UPDATE { CASCADE | NO ACTION } ] 
            [ NOT FOR REPLICATION ] 
        ] 
        | CHECK [ NOT FOR REPLICATION ] 
        ( logical_expression ) 
    } 

< table_constraint > ::= [ CONSTRAINT constraint_name ] 
    { [ { PRIMARY KEY | UNIQUE } 
        [ CLUSTERED | NONCLUSTERED ] 
        { ( column [ ASC | DESC ] [ ,...n ] ) } 
        [ WITH FILLFACTOR = fillfactor ] 
        [ ON { filegroup | DEFAULT } ] 
    ] 
    | FOREIGN KEY 
        [ ( column [ ,...n ] ) ] 
        REFERENCES ref_table [ ( ref_column [ ,...n ] ) ] 
        [ ON DELETE { CASCADE | NO ACTION } ] 
        [ ON UPDATE { CASCADE | NO ACTION } ] 
        [ NOT FOR REPLICATION ] 
    | CHECK [ NOT FOR REPLICATION ] 
        ( search_conditions ) 
    }

nee dus

[whoami]

Wat ik dus zal doen:

De tabellen creeëren dmv de SELECT INTO ... FROM clause
En dan een clustered index maken op die tabel, waarbij ik de filegroup van die clustered index specifieer. Op die manier zal die tabel op de juiste filegroup moeten komen.....

Ff checken...

[whoami]

\o/
Works like a charm.

[Delphi32]

Ik zat net te kijken of je table scripts niet gewoon via SQL-DMO zou kunnen genereren (en dat kan: zie MSDN) maar je bent er al uit zie ik

[whoami]

Kut, het zou natuurlijk wel mooi zijn als ik mijn historisch 'environment' op die manier kan creeëren, maar ik kan het eigenlijk toch niet doen.

Ik zit nl. met het probleem van database - aanpassingen:
Als ik een DB aanpassing doe, dan moet ik m'n historisch 'environment' ook gaan aanpassen. Dit zou ik dan doen door m'n history tables te backupen, te droppen, opnieuw te genereren en de informatie te restoren.
Hier zit ik dan met het probleem dat ik m'n 'mapping' niet weet; stel dat een column van tabel A naar tabel B gemoved wordt, dan moet dit ook in de history doorgevoerd worden. Dit kan ik onmogelijk automatisch laten doen.

Ik denk dus dat er niets anders opzit om m'n history tabellen ook in m'n data-model op te nemen (visio file). Indien er iets aan m'n db model veranderd, dan creeër ik een patch daarvoor dmv een aanpassing in m'n visio.
Dit is natuurlijk wel kut want nu mag ik zo'n 100 tabellen ofzo manueel gaan maken in Visio.

[P_de_B]

Als je nu alle akties op de db met script doet, dan kunt je toch redelijk eenvoudig diezelfde aktie op de history tabellen doen?

ALTER TABLE MyTable ADD Bla (int) wordt dan ook ALTER TABLE MyTable_History ADD Bla (int)

[whoami]

P_de_B schreef op donderdag 16 december 2004 @ 12:23:
Als je nu alle akties op de db met script doet, dan kunt je toch redelijk eenvoudig diezelfde aktie op de history tabellen doen?

De DB patches worden hier gemaakt dmv een aanpassing in de visio file, visio een DB script laten genereren, dit script uitvoeren en dan dmv RedGate tools een vergelijking te doen tussen deze nieuwe DB en de laatst gekende versie van de DB. Op die manier wordt er een patch script (DDL file) gemaakt die de 'oude db' kan upgraden naar een nieuwe versie.

Wat ik me nu wel bedenk: ik kan een script maken dat uitgevoerd wordt als patchxxx die de tabellen automatisch genereerd, en in volgende patches moet er dan idd manueel nog wat code bijgeschreven worden om de history tables te gaan upgraden.

In m'n programma die de DB gaat gaan creeëren (dmv het aanroepen van de main DDL en de bijhorende patches), kan ik ook een optie maken waarin je de history tables naar een andere filegroup kunt plaatsen.