visual-studio-2010 - vista - todo visual studio code

¿Mejores prácticas para rellenar datos estáticos con un proyecto de base de datos de Visual Studio 2010?

Question

¿Cómo llena su base de datos con datos estáticos controlados por fuente utilizando un proyecto de base de datos de Visual Studio? He intentado las tres estrategias a continuación, encontrando que cada una es progresivamente mejor que la anterior. Estoy usando pero no estoy completamente satisfecho con la estrategia 3. ¿Tiene otra alternativa?

1. Coloque los scripts de inserción en la carpeta "Planes de generación de datos". Consulte los scripts en el archivo "Script.PostDeployment.sql" para incluirlos en el proceso de implementación.

   - ventaja: sencillo
   - inconveniente: slooooooow
   - inconveniente: las implementaciones posteriores primero deben eliminar los datos estáticos o verificar que no existan datos => ineficientes

2. Inserte los datos en la base de datos la primera vez utilizando el método más conveniente (por ejemplo, podría ser la función de la tabla de edición SSMS). Extraiga esos datos utilizando la utilidad de línea de comandos bcp para crear un montón de archivos de datos y agregarlos a su proyecto. Cree un script al que se hace referencia en el archivo "Scripts.PostDeployment.sql" que ejecuta una declaración de "inserción masiva" para cada archivo de datos.

   - ventaja: mucho más rápido que insertar declaraciones
   - ventaja: puede aprovechar la función de la tabla de edición de SSMS
   - inconveniente: cada declaración de inserción masiva requiere un nombre de archivo completamente calificado para el archivo de datos, por lo que si los archivos de datos se encuentran en mi máquina en "C: / Projects / Dev / Source / foo.dat", la máquina de desarrollo remoto también debe tenerlos en esa ubicación o la instrucción de inserción masiva falla
   - inconveniente: debe eliminar los datos estáticos existentes antes de ejecutar las instrucciones de inserción masiva en implementaciones posteriores

3. Cree tablas temporales durante la implementación para mantener los datos estáticos y use la instrucción de fusión sql para sincronizar estas tablas con las tablas de destino. Ver either de these publicaciones del blog.

   - ventaja: parece que sql merge tiene la semántica perfecta para el problema
   - inconveniente: la lógica de esta estrategia se repite en cada archivo - inconveniente: las definiciones de tabla se repiten como tablas temporales en los archivos de combinación de SQL

¿Hay una estrategia alternativa superior? Renuncié a la estrategia 1 porque era demasiado lenta. No me gusta la estrategia 2 debido al problema del nombre de archivo completo. Estoy satisfecho pero no me emociona la estrategia 3. ¿Existe una mejor práctica?

Answer 1

Así es como resolví este problema en caso de que alguien más lo encuentre útil ...

La estrategia es establecer una variable sqlcmdvars antes de construir el proyecto de base de datos. Esta variable contendría la ruta absoluta a la carpeta de compilación a la que se puede hacer referencia desde el script posterior a la implementación. Entonces sería un asunto simple utilizar eso en el script de implementación para cualquier archivo o recurso adicional que pueda necesitar. La ventaja de esta estrategia es que todas las rutas son relativas al archivo del proyecto en lugar de requerir una ruta compartida codificada.

Cree un nuevo nombre de variable de comando Sql $ (MSBuildProjectDirectory). Esto se anulará en el script prebuild.

Cree un script msbuild que establezca la variable de comando sql y construya la base de datos.

<Project ToolsVersion="4.0" DefaultTargets="BuildDatabase" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)/MSBuildCommunityTasks/MSBuild.Community.Tasks.Targets"/>
<PropertyGroup>
<DatabaseServer>(Local)</DatabaseServer>
<DeploymentConnectionString>Data Source=$(DatabaseServer)%3BIntegrated Security=True%3BPooling=False</DeploymentConnectionString>
<Configuration>Release</Configuration>
</PropertyGroup>
<Target Name="BuildDatabase">
<!-- Sets the projet path variable so that the post deployment script can determine the location of the bulk insert csv files. -->
<XmlUpdate
Prefix="urn"
Namespace="urn:Microsoft.VisualStudio.Data.Schema.Package.SqlCmdVars"
XmlFileName="$(MSBuildProjectDirectory)/DatabaseProjectName/Properties/Database.sqlcmdvars"
XPath="/urn:SqlCommandVariables/urn:Properties/urn:Property[urn:PropertyName=''MSBuildProjectDirectory'']/urn:PropertyValue"
Value="$(MSBuildProjectDirectory)/DatabaseProjectName" />
<MSBuild
Projects="DatabaseProjectName/DatabaseProjectName.dbproj"
Properties="Configuration=$(Configuration);
TargetDatabase=DatabaseName;
TargetConnectionString=$(DeploymentConnectionString);
GenerateDropsIfNotInProject=True;
BlockIncrementalDeploymentIfDataLoss=False;
DeployToDatabase=True;
IgnorePermissions=True"
Targets="Build;Deploy">
<Output TaskParameter="TargetOutputs" ItemName="SqlFiles"/>
</MSBuild>
</Target>

Actualice su script de implementación posterior de la siguiente manera ...

BULK INSERT [dbo].[TableName] FROM ''$(MSBuildProjectDirectory)/Scripts/Post-Deployment/Data/YourDataFile.csv''
WITH (FIELDTERMINATOR = '','', ROWTERMINATOR=''/n'')

Answer 2

En su script insert.sql, puede poner un GUID en la tabla [__RefactorLog] (que es una tabla del sistema utilizada por la implementación) y verificar si este GUID existe antes de insertar sus datos de esta manera:

: setvar SOMEID "784B2FC9-2B1E-5798-8478-24EE856E62AE" // crear guid con Tools / CreateGuid en VS2010

SI NO EXISTE (SELECCIONE [OperationKey] DESDE [dbo]. [__ RefactorLog] donde [OperationKey] = ''$ (SOMEID)'')

EMPEZAR

...

INSERT INTO [dbo]. [__ RefactorLog] ([OperationKey]) valores (''$ (SOMEID)'')

FIN

Luego inserte datos solo si no existen o si desea (cambiando el Guid).

Answer 3

Puede usar el resultado del esquema del proyecto de la base de datos para actualizar la base de datos de destino. Hay una herramienta cmd para ejecutarlo en otra máquina que no está a la vista de usted vs2010 IDE

Así que sus datos seguirán siendo los mismos, a menos que tenga caídas en alguna columna

Answer 4

Todavía no hemos implementado nuestro proyecto de db VS 2010 en Producción, pero para nuestro proyecto interno cargamos la base de datos de producción en la base de datos de destino y compilamos / implementamos durante la fase de desarrollo / prueba. Dicho esto, entiendo que probablemente no funcionará para usted Tim si tiene varias bases de datos de productos y datos estáticos que se distribuyen a cada uno. Pero, se puede hacer para las tiendas de un solo producto como la nuestra.