与项目中的SQL Server项目或本地mdf文件持续集成的最佳实践

Question

今天我维护的项目非常混乱，需要大量的重构并在客户端计算机上发布。

我知道我可以添加一个只包含数据库脚本的 SQL Server数据库项目，并创建一个.dacpac文件，允许我自动更改客户端数据库。

另外，我知道我可以将.mdf文件添加到App_Data甚至Solution_Data文件夹，并在那里添加我的数据库。我想已经存在的localDb允许我在没有SQL Server的情况下启动我的解决方案

至此我知道实体框架与它自己的迁移一起存在。但我不想使用它，besouse我不能添加和更改索引的迁移，当我需要描述困难的迁移场景时，我没有灵活性。

我的目标：

1. 自动生成迁移脚本到客户端数据库。
2. 让我的解决方案自成一体，任何来到项目的新程序员甚至不需要在他的机器上安装SQL Server。
3. 能够通过1-2次点击更新本地（开发）基础。
4. 能够在db更改的历史记录中移回（我有TFS服务器）
5. 能够在解决方案中使用最新数据库方案清理（仅限字典或查找表）数据库。
6. 此外，我希望能够自动或非常简单地更新我的数据库模型（ EF 或.dbml）。

那我要问的是什么：

• 如果我想实现目标，使用这两种方法有什么优点和缺点？

• 可以说我应该使用这种工具的组合吗？

• 或者我不知道MS的其他现有工具？

• 有没有办法从这个数据库更新我的 DAL 模型？

Answer 1

  

如果我想实现目标，使用这两种方法的优点和缺点是什么？

使用数据库项目允许您对所有数据库对象进行版本控制。您可以发布到各种数据库实例并逐步推出更改，而不必删除并重新创建数据库，从而保留数据。这些更改可以是dacpac，SQL脚本的形式，也可以通过VS接口完成。使用部署前和部署后脚本以及发布配置文件，您可以获得对部署的大量控制。开发人员将被要求安装SQL Server（开发人员/快递版通常足够好）。

LocalDB更容易使用 - 您可以直接在数据库中进行更改，而无需发布。 LocalDB没有内置的发布过程来推动对其他实例的更改。无需安装SQL Server。

如果需要对数据库对象进行版本控制，如果有多个用户同时进行更改，或者如果有多个应用程序使用同一数据库，则使用数据库项目。如果这些条件都不适用，则使用LocalDB;对于需要自己的独立数据库的小型应用程序，请使用。

  

可以说我应该使用这种工具的组合吗？

是。根据Kevin在下面的评论，＆＃34;如果将数据库项目设置为您的启动项目，点击F5将自动将其部署到LocalDB。在这种情况下，您甚至不需要发布配置文件。＆＃34;

  

或者我不知道MS的其他现有工具？

接近{p> Entity Framework's Code First方法。

  

有没有办法从这个DB更新我的DAL模型？

Entity Framework's POCO generator除非您对DAL类进行更改，否则这些更改会在您下次运行生成器时丢失。

有一个名为SqlSharpener的新工具可以从数据库项目中的SQL文件生成类。我没有用它，所以我不能保证，但看起来很有希望。

Answer 2

为数据库更改生成客户端脚本的一种方法是使用像ERWin这样的数据库建模工具，它具有免费的社区版本。满足数据库版本控制要求和简单脚本生成的最佳方法是Redgate SQL Source Control。使用Redgate工具，您将满足前面提到的五个目标。此外，您现在可以根据目标6中的要求更改数据库架构（即数据库第一种方法）后单击更新EF模型。

我建议不要使用LocalDB。它始终会使源控制出现问题，例如＆＃34;数据库文件正在使用中并且无法提交...“此外，除非开发人员，否则项目中的开发人员将无法使用常用的更新数据集将测试数据添加到数据库并要求其他人获取最新版本并覆盖他们自己的数据库或者通过前面提到的工具生成更新脚本，并要求每个开发人员在他的localDB上运行它。 在您的情况下，最好的方法是在网络上使用SQL Server。所有开发人员使用的主版本。由于您使用前面提到的工具对数据库进行了版本控制，因此您可以回滚数据库服务器中的任何错误更改。

如果您认为RedGate工具对于项目的预算来说是昂贵的。第二种方法是从数据库生成具有所有数据库对象的单个SQL文件，其他开发人员根据其更改在源代码管理中更新SQL文件。这可以通过在visual studio中使用模式比较工具并将生成的脚本附加到源控件中的SQL文件来轻松完成。使用EF DB First方法，您不必像EF代码中那样添加许多迁移类。