Entity Framework 4.3 Stratégie de migration pour la base de données utilisée par plusieurs applications

Question

J'ai travaillé sur une application ASP.NET Entity Framework 4.3 Code-First, qui régit le modèle pour les parties de la base de données qui l'intéressent. Comme cette base de données sera utilisée par plusieurs autres applications (certaines n'utilisant pas ef, donc ne pouvant pas importer de modèles), l'idée était de créer la base de données de base avec mon application. Après cela, le DBA pourrait ajouter d'autres champs et tables non utilisés par mon application si nécessaire.

Le problème se pose lors de la mise en œuvre des modifications apportées au modèle dans mon application. Notre idée était d'utiliser la nouvelle fonctionnalité Migrations de EF 4.3 pour créer des scripts (option -script) en pointant vers notre machine locale dev db (SQLCompact), qui sera ensuite transmise à l'administrateur pour migrer la base de données dev actuelle (MS SQL 2008) que toutes les autres applications utilisent. Cela a toutefois causé des problèmes, car lorsque j'ai commencé à tester (en pointant vers le serveur SQL), l'application ne pouvait lire aucune relation de clé étrangère, ce qui donnait des erreurs sur le fait que ces colonnes n'existaient pas. Je me demande si cela est causé par les différences dans la traduction de SQL Compact et SQL Server (EF à SQL), ou un autre problème est la cause. Dois-je être dérangé par les migrations EF pour ce type d'environnement d'applications multiples à base de données 1-DB? Dois-je exécuter toutes mes migrations directement sur le serveur SQL? Y a-t-il une stratégie de changement entièrement différente que je devrais utiliser? Toute aide ou orientation serait appréciée.

Answer 1

Eh bien, vous pourriez essayer d'installer SQL Server Express localement au lieu d'utiliser compact. Cela devrait éliminer toutes les différences entre compact et standard.