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

Question

今天我维护的项目非常混乱,需要大量的重构并在客户端机器上发布.

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

此外,我知道我可以只添加一个.mdf文件到App_Data甚至Solution_Data文件夹,有我的数据库存在.我认为localDb已经存在允许我在没有SQL Server的情况下启动我的解决方案

而且我知道实体框架存在于它自己的迁移中.但我不想使用它,besouse我无法添加和更改索引的迁移,当我需要描述困难的迁移场景时,我没有灵活性.

我的目标:

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

那么我要问的是:

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

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

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

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

Answer 1

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

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

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

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

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

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

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

实体框架的Code First方法非常接近.

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

除非您对DAL类进行更改,否则实体框架的POCO生成器运行良好,然后在您下次运行生成器时这些更改会丢失.

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