Como devo organizar o meu script ddl mestre

votos
11

Atualmente, estou criando um ddl mestre para o nosso banco de dados. Historicamente temos usado backup / restauração para a versão nosso banco de dados, e não manteve quaisquer scripts DDL. O esquema é muito grande.

Meu pensamento atual:

  • Quebre script em partes (possivelmente em scripts separados):

    1. a criação da tabela
    2. adicionar índices
    3. adicionar gatilhos
    4. adicionar restrições
  • Cada script iria ser chamado pelo script mestre.

  • Eu poderia precisar de um script para descartar restrições temporariamente para testes
  • mesas pode ser órfãs no esquema, eu pretendo identificar tabelas suspeitos.

Qualquer outro conselho?

Edit: Além disso, se alguém souber boas ferramentas para automatizar parte do processo, estamos usando o MS SQL 2000 (velho, eu sei).

Publicado 07/08/2008 em 18:18
fonte usuário
Em outras línguas...                            


7 respostas

votos
3

Acho que a idéia básica é bom.

A coisa agradável sobre a construção de todas as tabelas em primeiro lugar e, em seguida, a construção de todas as restrições, é que as tabelas podem ser criadas em qualquer ordem. Quando eu fiz isso eu tinha um arquivo por tabela, que eu coloquei em um diretório chamado "Tabelas" e, em seguida, um script que executou todos os arquivos no diretório. Da mesma forma que eu tinha uma pasta para scripts restrição (que fez chave estrangeira e índices muito), que foram executados quando após as tabelas foram construídas.

Gostaria de separar a construção dos gatilhos e procedimentos armazenados e executar estes últimos. O ponto sobre estes é que eles podem ser executados e re-executar no banco de dados sem afetar os dados. Isto significa que você pode tratá-los como código comum. Você deve incluir "se existe ... gota" declarações no início de cada script gatilho e procedimento, para torná-los re-executável.

Assim, a ordem seria

  1. a criação da tabela
  2. adicionar índices
  3. adicionar restrições

Então

  1. adicionar gatilhos
  2. adicionar procedimentos armazenados

No meu projeto atual estamos usando MSBuild para executar os scripts. Há alguns alvos de extensão que você pode obter para ele que lhe permitem chamar scripts sql. No passado, eu usei perl que foi bom também (e arquivos em lote ... que eu não recomendaria - o estiver muito limitada).

Respondeu 11/09/2008 em 18:13
fonte usuário

votos
1

há uma boas ferramentas que irão iterar todo o servidor SQL e extrair toda a tabela, visão proceedures armazenados e defintions UDF para o sistema de arquivos local como scripts SQL (arquivos de texto). Eu usei isso com 2005 e 2008, não sei como ele wil trabalhar com 2000 embora. Confira http://www.antipodeansoftware.com/Home/Products

Respondeu 29/08/2010 em 07:50
fonte usuário

votos
1

Se você está procurando uma ferramenta de automação, muitas vezes tenho trabalhado com EMS SQLManager, que lhe permite gerar automaticamente um script ddl a partir de um banco de dados.

inserções de dados em tabelas de referência pode ser obrigatória antes de colocar o seu banco de dados on line. Isso pode até ser considerada como parte do script ddl. EMS também pode gerar scripts para inserções de dados de bancos de dados existentes.

Necessidade de índices não pode ser adequadamente estimada na fase ddl. Você só precisa declará-los para chaves primárias / estrangeiros. Outros índices devem ser criados mais tarde, uma vez que pontos de vista e consultas foram definidas

Respondeu 16/09/2008 em 20:48
fonte usuário

votos
1

@Adão

Ou como sobre apenas pelo domínio - um agrupamento útil de tabelas relacionadas no mesmo arquivo, mas separado do resto?

O único problema é se alguns domínios (neste sistema legado um pouco) estão fortemente acoplados. Além disso, você tem que manter as dependências entre os diferentes sub-scripts.

Respondeu 07/08/2008 em 18:31
fonte usuário

votos
1

Investir o tempo para escrever um script genérico "cair todas as restrições", para que você não tem que mantê-lo.

Um cursor sobre as seguintes afirmações faz o truque.

Select * From Information_Schema.Table_Constraints 

Select * From Information_Schema.Referential_Constraints
Respondeu 07/08/2008 em 18:25
fonte usuário

votos
1

O que você tem lá parece ser muito bom. Minha empresa tem de vez em quando, para bases de dados grande o suficiente, quebrado-lo ainda mais, talvez ao nível do objeto individual. Desta forma, cada tabela / index / ... tem seu próprio arquivo. Pode ser útil, pode ser um exagero. Realmente depende de como você está usando.

@Justin

Por domínio é principalmente sempre suficiente. Concordo que há algumas complexidades de lidar com quando fazê-lo desta maneira, mas isso deve ser fácil de manusear.

Eu acho que este método fornece um pouco mais de separação (que em um grande banco de dados que você venha a apreciar) e ainda fazer-se muito manejável. Nós também escrever scripts Perl que fazem um monte do processamento destes arquivos DDL, de modo que pode ser uma opção de uma boa maneira de lidar com isso.

Respondeu 07/08/2008 em 18:24
fonte usuário

votos
0

Eu já organizado meu código DDL organizado por um arquivo por entidade e fez uma ferramenta que combinou isso em um único script DDL.

Meu ex-empregador utilizado um esquema em que toda a tabela DDL foi em um arquivo (armazenado na sintaxe Oracle), indicies em outro, restrições em uma terceira e estáticas dados em uma quarta. Um script de alteração foi mantido em paralelo com este (mais uma vez no Oracle). A conversão para SQL era manual. Foi uma bagunça. Na verdade, eu escrevi uma ferramenta acessível que irá converter a Oracle DDL para SQL Server (que funcionou 99,9% do tempo).

Tenho recentemente passou a usar Visual Studio Team System para profissionais de banco de dados . Até agora ele funciona bem, mas existem algumas falhas, se você usar funções CLR no banco de dados.

Respondeu 19/08/2008 em 07:19
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more