Refactoring di oggetti di database in ambiente di collaborazione in team

Con Visual Studio Premium è possibile gestire le modifiche inserente la rappresentazione offline dello schema del database, denominato progetto di database, in un sistema di controllo della versione. Uno dei membri di un team può modificare il progetto di database, ma è necessario compilare e distribuire tali modifiche in un database attivo. In questa situazione, possono essere presenti fino a quattro rappresentazioni del database:

• Il server database, che contiene database attivo e dati.

• Il progetto di database, che è la rappresentazione offline dello schema di database.

• Il file .dbschema compilato che contiene informazioni necessarie per distribuire lo schema del database in qualsiasi database e server di destinazione. Il file viene creato ogni volta che si compila il progetto di database.

• L'archivio per il controllo delle versioni, in cui viene tenuta traccia di tutte le modifiche apportate dai membri del team al progetto di database.

Per ulteriori informazioni, vedere Avvio dello sviluppo in team di database.

Refactoring in un ambiente di collaborazione in team

Se si utilizza il refactoring per rinominare un oggetto di database o spostarlo in un altro schema, gli altri oggetti che fanno riferimento all'oggetto rinominato o spostato vengono automaticamente aggiornati con il nuovo nome o schema. È ad esempio possibile rinominare una colonna in una tabella affinché ogni stored procedure che fa riferimento a tale colonna venga automaticamente aggiornata con il nuovo nome. Per ulteriori informazioni, vedere Ridenominazione di tutti i riferimenti a un oggetto di database o Spostamento di un oggetto di database in un altro schema.

Per poter aggiornare un oggetto di database, è necessario estrarre dal controllo del codice sorgente i file relativi a tutti gli oggetti da aggiornare. Se l'opzione del controllo del codice sorgente è stata impostata allo scopo di estrarre automaticamente i file, il tentativo di estrazione verrà eseguito senza avvisare. In caso contrario, verrà richiesto di estrarre i file.

L'operazione di refactoring non riesce nelle situazioni seguenti:

• Se uno o più file sono stati bloccati da un altro utente, verrà visualizzato un messaggio di errore e l'operazione di refactoring verrà annullata. È necessario attendere che i file vengano sbloccati per poter tentare di nuovo l'operazione.

• Se le versioni estratte sono più recenti di quelle del progetto corrente, verrà visualizzato un messaggio di errore e l'operazione di refactoring verrà annullata. È necessario risolvere le differenze di versione tra i file per poter ritentare l'operazione.

• Se viene richiesto di estrarre i file e si sceglie Annulla, l'operazione di refactoring verrà annullata.

  Nota

  Quando si rinomina un oggetto di database, il file con estensione sql in cui tale oggetto è definito non viene rinominato. Sarà possibile rinominare il file manualmente in Esplora soluzioni.

Log di refactoring e mantenimento della finalità

Quando si utilizza il refactoring per rinominare o spostare un oggetto di database, il file NomeProgetto.refactorlog viene aggiornato con i dettagli dell'operazione. Quando si distribuiscono le modifiche, il file di log consente di garantire la realizzazione dello scopo delle modifiche, in quanto lo script di distribuzione contiene le operazioni a tale scopo. La distribuzione, ad esempio, può generare l'istruzione sp_rename per una colonna anziché eliminare e creare istruzioni.

Se due o più sviluppatori apportano modifiche che aggiornano il log di refactoring, le modifiche nel file di log verranno unite. Il file .refactoring è un file XML che dispone di un schema semplice in modo che l'unione degli aggiornamenti risulti facilitato. Ogni operazione include una data e ora in modo che sia possibile assicurarsi che le operazioni di refactoring siano state applicate nell'ordine corretto.

Attenzione
Se si uniscono automaticamente le modifiche nel log del refactoring, si potrebbero verificare gli errori. È consigliabile verificare sempre i risultati di un'unione automatica o unire manualmente le modifiche manualmente prima di tentare di distribuire il progetto di database.

Il log di refactoring ha un aspetto analogo all'esempio seguente.

<?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>

In questo log di esempio, sono registrate due operazioni di refactoring. Nella prima operazione, la tabella [AbsenceHistory] è stata spostata dallo schema [Person] allo schema al [HumanResources]. Nella seconda operazione, la colonna [column_1] della tabella [AbsenceHistory] è stata rinominata in [EmployeeID].

Vedere anche

Concetti

Creazione e gestione di database e applicazioni di livello dati in Visual Studio

Ridenominazione di tutti i riferimenti a un oggetto di database

Spostamento di un oggetto di database in un altro schema

Refactoring del codice e dei dati del database