Refactorizar objetos de base de datos en un entorno de equipo

En Visual Studio Premium los cambios se controlan agregando, a un sistema de control de versiones, la representación sin conexión del esquema de base de datos, que se denomina el proyecto de base de datos. El proyecto de base de datos puede ser modificado por cualquier miembro del equipo, pero después esos cambios deben generarse e implementarse en una base de datos activa. En una situación como ésta, existen hasta cuatro representaciones de la base de datos:

• El servidor de bases de datos, que contiene la base de datos activa y los datos.

• El proyecto de base de datos, que es la representación sin conexión del esquema de base de datos.

• El archivo .dbschema compilado, que contiene información necesaria para implementar ese esquema de la base de datos en cualquier servidor y base de datos de destino. Este archivo se crea cada vez que se compila el proyecto de base de datos.

• El repositorio de control de versiones, que realiza un seguimiento de todos los cambios que cualquier miembro del equipo realiza en el proyecto de base de datos.

Para obtener más información, vea Iniciar el desarrollo de bases de datos de equipo.

Refactorización en un entorno de equipo

Si se utiliza la refactorización para cambiar el nombre de un objeto de base de datos o moverlo a un esquema diferente, los demás objetos que hacen referencia al objeto que se ha movido o al que se ha cambiado el nombre se actualizan automáticamente con el nuevo nombre o esquema. Por ejemplo, si cambia el nombre de una columna de una tabla, el nombre de dicha columna se actualizará en los procedimientos almacenados que hagan referencia a la columna. Para obtener más información, vea Cambiar el nombre de todas las referencias a un objeto de base de datos o Mover un objeto de base de datos a un esquema diferente.

Antes de actualizar un objeto de base de datos, es preciso desproteger del control de código fuente los archivos correspondientes a todos los objetos que es preciso actualizar. Si ha establecido la opción de control de código fuente para desproteger los archivos automáticamente, el intento de desprotección se realiza de manera silenciosa. En caso contrario, se le pedirá que desproteja los archivos.

En las siguientes situaciones, se produce un error en la operación de refactorización:

• Si otra persona ha bloqueado uno o más de los archivos, aparece un mensaje y se cancela la operación de refactorización. Deberá esperar a que se desbloqueen los archivos para poder volver a intentar la operación.

• Si las versiones que se desprotegen son más recientes que las versiones contenidas en el proyecto, aparece un mensaje de error y se cancela la operación de refactorización. Es preciso conciliar las versiones de los archivos antes de volver a intentar la operación.

• Si se le pide que desproteja los archivos y hace clic en Cancelar, se cancela la operación de refactorización.

  Nota

  Al cambiar el nombre de un objeto de base de datos, no se cambia el nombre del archivo .sql en el que se define ese objeto. Puede cambiar el nombre del archivo manualmente en el Explorador de soluciones.

Registros de refactorización y protección del propósito

Cuando se utiliza la refactorización para cambiar el nombre de un objeto de base de datos o moverlo, el archivo ProjectName.refactorlog se actualiza con los detalles de esa operación. Al implementar los cambios, el registro ayuda a conservar el propósito de los cambios porque el script de implementación contiene operaciones que conservan ese propósito. Por ejemplo, la implementación puede emitir una instrucción sp_rename para una columna en lugar de instrucciones drop y create.

Si dos o más desarrolladores realizan modificaciones que actualizan el registro de refactorización, los cambios del archivo de registro se deberán combinar. El archivo .refactoring es un archivo XML con un esquema simple, de modo que no debe resultar complicado combinar las actualizaciones. Cada operación incluye una fecha y hora para que pueda asegurarse de que las operaciones de refactorización se aplican en el orden correcto.

Precaución
Si los cambios del registro de refactorización se combinan automáticamente, pueden producirse errores. Siempre deben revisarse los resultados de una combinación automática o combinarse los cambios manualmente antes de intentar implementar el proyecto de base de datos.

El registro de refactorización tendrá un aspecto parecido al ejemplo siguiente:

<?xml version="1.0" encoding="utf-16"?>
<Operations>
  <Operation Name="Move Schema" Key="677a0ee6-1707-413a-985f-b392b1a2d68b" ChangeDateTime="04/07/2008 21:59:00">
    <Property Name="ElementName" Value="[Person].[AbsenceHistory]" />
    <Property Name="ElementType" Value="ISql90Table" />
    <Property Name="NewSchema" Value="HumanResources" />
    <Property Name="IsNewSchemaExternal" Value="True" />
  </Operation>
  <Operation Name="Rename Refactor" Key="fb88992c-cd6e-43d0-aa54-ed80f155d202" ChangeDateTime="04/07/2008 21:59:26">
    <Property Name="ElementName" Value="[HumanResources].[AbsenceHistory].[column_1]" />
    <Property Name="ElementType" Value="ISqlSimpleColumn" />
    <Property Name="ParentElementName" Value="[HumanResources].[AbsenceHistory]" />
    <Property Name="ParentElementType" Value="ISql90Table" />
    <Property Name="NewName" Value="EmployeeID" />
  </Operation>
</Operations>

En este registro de ejemplo, se han registrado dos operaciones de refactorización. En la primera operación, se movió la tabla [AbsenceHistory] del esquema [Rol] al esquema [HumanResources]. En la segunda operación, se cambió el nombre de la columna [column_1] de la tabla [AbsenceHistory] por el de [EmployeeID].

Vea también

Conceptos

Crear y administrar aplicaciones de capa de datos y bases de datos en Visual Studio

Cambiar el nombre de todas las referencias a un objeto de base de datos

Mover un objeto de base de datos a un esquema diferente

Refactorizar código de base de datos y datos