今天我维护的项目有非常困惑的数据库,需要大量重构并在客户端计算机上发布。
我知道我可以添加一个 SQL Server 数据库 项目,该项目仅包含数据库脚本并创建一个 .dacpac
文件,该文件允许我自动更改客户端数据库。
此外,我知道我可以将 .mdf
文件添加到 App_Data
甚至 Solution_Data
文件夹中,并将我的数据库放在那里。我想已经存在的 localDb
允许我在没有 SQL Server 的情况下启动我的解决方案
最后我知道 Entity Framework 存在它自己的迁移。但我不想使用它,因为我无法通过它的迁移添加和更改索引,并且当我需要描述困难的迁移场景时我没有足够的灵 active 。
我的目标:
- 自动生成到客户端数据库的迁移脚本。
- 使我的解决方案独立,任何参与项目的新程序员甚至不需要在他的计算机上安装 SQL Server。
- 只需点击 1-2 次即可更新本地(开发)基础。
- 能够回溯数据库更改的历史记录(我有 TFS 服务器)
- 能够在具有最新数据库方案的解决方案中拥有干净的数据库(仅使用字典或查找表)。
- 此外,我希望能够自动或非常简单地更新我的数据库模型(EF 或
.dbml
)。
所以我要问什么:
如果我想实现我的目标,使用这两种方法的优点和缺点是什么?
我应该使用这些工具的某种组合吗?
或者我不知道 MS 的其他现有工具吗?
有办法从此数据库更新我的 DAL 模型吗?
最佳答案
What's a strengths and weaknesses of using this 2 approaches if I want to achive my goals?
使用数据库项目允许您对所有数据库对象进行版本控制。您可以发布到各种数据库实例并逐步推出更改,而不必删除并重新创建数据库,从而保留数据。这些更改可以采用 dacpac、SQL 脚本的形式,或者直接通过 VS 界面完成。您可以使用部署前和部署后脚本以及发布配置文件对部署进行大量控制。开发人员需要安装 SQL Server(开发人员/快速版通常就足够了)。
LocalDB 更容易使用——您可以直接在数据库中进行更改,而无需发布。 LocalDB 没有内置的发布流程来将更改推送到其他实例。无需安装 SQL Server。
如果您需要对数据库对象进行版本控制,如果您有多个用户同时进行更改,或者您有多个应用程序使用同一数据库,请使用数据库项目。如果这些条件都不适用或者需要自己的独立数据库的小型应用程序,请使用 LocalDB。
Can be that I should use sort of combination of this tools?
是的。根据 Kevin 下面的评论,“如果数据库项目设置为您的启动项目,按 F5 会自动将其部署到 LocalDB。在这种情况下,您甚至不需要发布配置文件。”
Or don't I know about other existing tool from MS?
Entity Framework's Code First方法已经很接近了。
Is there a way to update my DAL model from this DB?
Entity Framework's POCO generator除非您对 DAL 类进行更改,否则效果很好,否则这些更改会在您下次运行生成器时丢失。
有一个名为 SqlSharpener 的新工具它可以从数据库项目中的 SQL 文件生成类。我没有使用过它,所以我不能保证它,但它看起来很有前途。
关于sql - 与SQL Server项目或项目中本地mdf文件持续集成的最佳实践,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30208313/