esquema ejemplo drop create consultar sql sql-server schema ddl

ejemplo - rename schema sql server



¿Cómo debería organizar mi script master ddl? (7)

Actualmente estoy creando un master ddl 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:

  • Romper el script en partes (posiblemente en scripts separados):

    1. creación de mesa
    2. agregar índices
    3. agregar desencadenantes
    4. agregar restricciones

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

  • Es posible que necesite una secuencia de comandos para eliminar temporalmente las restricciones para las pruebas
  • Puede haber tablas huérfanas en el esquema, planeo identificar las tablas sospechosas.

¿Algún otro consejo?

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

@Adán

¿O qué tal solo por dominio: una agrupación útil de tablas relacionadas en el mismo archivo, pero separada del resto?

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

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

Mi antiguo empleador usó un esquema donde todos los DDL de tabla estaban en un archivo (almacenado 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 (de nuevo 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).

Recientemente cambié al uso de Visual Studio Team System para profesionales de bases de datos . Hasta ahora funciona bien, pero hay algunas fallas si usa funciones CLR dentro de la base de datos.

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 compilación de los desencadenantes y los procedimientos almacenados, y ejecutaría estos últimos. 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.

Entonces el orden sería

  1. creación de mesa
  2. agregar índices
  3. agregar restricciones

Entonces

  1. agregar desencadenantes
  2. agregar procedimientos almacenados

En mi proyecto actual, estamos usando MSBuild para ejecutar los scripts. Existen algunos objetivos de extensión 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).

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 adecuadamente en la etapa ddl. Solo deberá declararlos para claves primarias / extranjeras. Otros índices deben crearse más tarde, una vez que las vistas y las consultas han sido definidas

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 a 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 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 hace 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.

hay 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 en el 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. Visite http://www.antipodeansoftware.com/Home/Products

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

Un cursor sobre las siguientes afirmaciones es el truco.

Select * From Information_Schema.Table_Constraints Select * From Information_Schema.Referential_Constraints