¿Cómo debo organizar mi secuencia maestra ddl?

Question

Actualmente estoy creando un ddl maestro para nuestra base de datos. Históricamente hemos utilizado backup/restore para versionar nuestra base de datos, y no hemos mantenido ningún scripts ddl. El esquema es bastante grande.

Mi pensamiento actual:

• guión rotura en partes (posiblemente en diferentes scripts):

  1. creación de la tabla
  2. añadir índices
  3. complemento desencadena
  4. añaden restricciones

• Cada script sería llamado por el script maestro.

• Necesitaría una secuencia de comandos para eliminar las restricciones temporalmente para la prueba
• Puede haber tablas huérfanas en el esquema, planeo identificar las tablas sospechosas.

¿Algún otro consejo?

Editar: También si alguien conoce buenas herramientas para automatizar parte del proceso, estamos usando MS SQL 2000 (viejo, lo sé).

Answer 1

Lo que tienes allí parece ser bastante bueno. En ocasiones, en el caso de una base de datos suficientemente grande, mi compañía la ha desglosado aún más, tal vez al nivel de objeto individual. De esta forma, cada tabla/índice/... tiene su propio archivo. Puede ser útil, puede ser excesivo. Realmente depende de cómo lo estés usando.

@Justin

Por dominio es sobre todo siempre es suficiente. Estoy de acuerdo en que hay algunas complejidades para tratar al hacerlo de esta manera, pero que debería ser lo suficientemente fácil de manejar.

Creo que este método proporciona un poco más de separación (que en una gran base de datos se puede apreciar) mientras se sigue haciendo bastante manejable. También escribimos scripts Perl que hacen gran parte del procesamiento de estos archivos DDL, por lo que podría ser una buena opción para manejarlos.

Answer 2

Invierta el tiempo para escribir un script genérico de "soltar todas las restricciones", para que no tenga que mantenerlo.

Un cursor sobre las siguientes afirmaciones hace el truco.

Select * From Information_Schema.Table_Constraints 

Select * From Information_Schema.Referential_Constraints 

Answer 3

@ Adam

O qué tal con solo dominio - una agrupación útil de las tablas relacionadas en el mismo archivo, pero separado del resto?

El único problema es si algunos dominios (en este sistema algo heredado) están estrechamente acoplados. Además, debe mantener las dependencias entre sus diferentes sub-guiones.

Answer 4

Anteriormente organicé mi código DDL organizado por un archivo por entidad y creé una herramienta que combinaba esto en un solo script DDL.

Mi antiguo empleador utilizaba un esquema en el que todas las tablas DDL estaban en un archivo (almacenadas en sintaxis de Oracle), indicios en otro, restricciones en un tercero y datos estáticos en un cuarto. Un script de cambio se mantuvo en paralelo con esto (nuevamente en Oracle). La conversión a SQL fue manual. Fue un desastre. De hecho, escribí una herramienta práctica que convertirá Oracle DDL en SQL Server (funcionó el 99.9% de las veces).

He cambiado recientemente a usar Visual Studio Team System for Database professionals. Hasta ahora funciona bien, pero hay algunas fallas si usa funciones CLR dentro de la base de datos.

Answer 5

Creo que la idea básica es buena.

Lo bueno de construir todas las tablas primero y luego construir todas las restricciones, es que las tablas se pueden crear en cualquier orden. Cuando hice esto, tenía un archivo por tabla, que puse en un directorio llamado "Tablas" y luego un script que ejecutó todos los archivos en ese directorio. Del mismo modo, tenía una carpeta para las secuencias de comandos de restricción (que también utilizaba la clave externa y los índices), que se ejecutaban cuando se creaban las tablas.

Yo separaría la construcción de los desencadenantes y los procedimientos almacenados, y los ejecutaré por última vez. El punto sobre esto es que se pueden ejecutar y volver a ejecutar en la base de datos sin afectar los datos. Esto significa que puedes tratarlos como el código ordinario. Debe incluir las sentencias "si existe ... soltar" al comienzo de cada secuencia de comandos de desencadenante y procedimiento, para que puedan volver a ejecutarse.

Así que el orden sería

1. creación de la tabla
2. añadir índices
3. añaden restricciones

Entonces

4. complemento desencadena
5. agregar almacenamiento pr ocedures

en mi proyecto actual que está utilizando MSBuild para ejecutar los scripts. Hay algunos extension targets que puede obtener y que le permiten llamar a los scripts sql. En el pasado he usado Perl, que también estaba bien (y archivos por lotes ... que no recomendaría, son muy limitados).

Answer 6

Si está buscando una herramienta de automatización, a menudo he trabajado con EMS SQLManager, que le permite generar automáticamente un script ddl desde una base de datos.

Las inserciones de datos en tablas de referencia pueden ser obligatorias antes de poner su base de datos en línea. Esto incluso se puede considerar como parte del script ddl. EMS también puede generar scripts para inserciones de datos de bases de datos existentes.

La necesidad de índices puede no estimarse correctamente en la etapa ddl. Solo deberá declararlos para claves primarias/extranjeras. Otros índices deben crearse más tarde, una vez que las vistas y consultas han sido definidas

Answer 7

hay unas herramientas ordenadas que iterarán a través de todo el servidor sql y extraerán toda la tabla, vista, procedimientos almacenados y definiciones UDF al sistema de archivos local como Scripts SQL (archivos de texto). Lo he usado con 2005 y 2008, aunque no estoy seguro de cómo funcionará con 2000.Check out http://www.antipodeansoftware.com/Home/Products