验证目标数据库架构是否符合实体框架中的内容？
我们有一个流程，我们的数据库人员使用我们的代码库将脚本更改（并使用 Juneau 对其进行版本化）到我们应用程序的数据库。他们擅长考虑新列为空，并且不会擦除现有数据，但偶尔会出现未完全传达的列重命名。因此，他们将对测试服务器上的数据库架构进行一些更改，我们将更新实体框架以处理这些更改，然后提交我们的代码。这个过程工作正常，除了需要部署的时候。
我们已设置 TFS 以将成功的构建部署到适当的服务器，但不能保证该环境的数据库已更新。我们不关心是否有额外的字段/表/视图/等。存在于目标数据库中，但我们希望更改构建以检查数据库是否至少包含 EF 知道的所有内容。
我查看了 这个问题，但我不需要模式完全匹配。另外，我们不希望它直接创建/修改数据库。 这个问题似乎是试图实现类似的理想，但仍然不是我们想要实现的目标。我们只是想要进行某种集成测试来验证我们的 EF 版本是否可以与目标架构配合使用。
We have a process where our database guys script changes (and version them using Juneau) to our application's database out-of-band with our code base. They're good at accounting for new columns being null, and not wiping existing data, but occasionally a column rename sneaks in that isn't fully communicated. So they will make some changes to the database schema on a testing server, we'll update Entity Framework to work with those changes, and then commit our code. This process works okay, except for when it's time to deploy.
We have TFS set up to deploy the successful build to the appropriate servers, but there's no guarantee that the database for that environment has been updated. We don't care if extra fields/tables/views/etc. exist in the target database, but we want change the build to check that the database contains at least everything EF is aware of.
I looked at this question, but I don't need the schema to match exactly. Plus, we don't want it creating/modifying the database directly. And this question seems like it's trying to achieve a similar ideal, but still not quite what we're looking to achieve. We just want a integration test of sorts to verify our version of EF will work with the target schema.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想知道为什么您尝试在不更改数据库的情况下部署应用程序。您的应用程序依赖于数据库，因此部署应始终在数据库之后完成。看起来您将投入大量时间来开发验证来修复不正确的部署过程（其中修复过程本身是正确的解决方案）。
无论如何，您可以创建数据库的一些“验证”，但这需要一些时间。如果您使用 EDMX 文件，可以将其作为 XML 打开并读取其 SSDL 描述所有预期的表、列、关系、视图（以 SELECT SQL 查询的形式）、存储过程和函数的部分。您可以解析此 XML 部分并使用系统数据库视图（
sys.tables、sys.columns...）来查询这些对象是否存在于数据库中。另一种方法是使用数据库差异。用于将当前测试数据库与目标数据库进行比较的工具。这将需要可以从命令行执行的工具，并且您必须解析其输出以查找重大更改。
I wonder why you try to deploy your application without changes to database. Your application is dependent on the database so the deployment should always be done after the database. It looks like you are going to invest a lot of time to develop validation to fix your incorrect deployment process (where fixing the process itself is the correct solution).
Anyway you can create some "validation" of the database but it will take some time. If you are using EDMX file you can open it as XML and read its SSDL part which describes all expected tables, columns, relations, views (in form of SELECT SQL queries), stored procedures and functions. You can parse this XML part and use system database views (
sys.tables,sys.columns, ...) to query if these objects exists in the database.Another approach can be using database diff. tool to compare your current test database with the target one. This will require the tool which can be executed from command line and you will have to parse its output to find breaking changes.