当有许多人在项目中工作时，所有人都可以改变数据库模式，单元测试/测试/验证的最简单方法是什么？我们迄今为止的主要建议是为每个表编写测试以验证列名称，约束等。你如何（单元）测试数据库模式？
其他任何人做了类似/更简单的事情吗？我们使用C＃与SQL Server，如果这有什么真正的区别。
更新：
一个可能的答案是使用Visual Studio for Database开发人员并使用代码的其余部分将您的架构保持在源代码管理中。这可以让你看到不同之处，你会得到谁改变了什么的历史。
或者，您可以使用像SQLCompare这样的工具来查看与另一个数据库相比已修改的内容。
这是一个有趣的问题！有很多工具用于测试存储过程，但不用于测试数据库模式。
您是否发现为代码编写的单元测试通常会发现数据库模式的任何问题？
我使用的一种方法是编写存储过程，将测试数据从开发人员的模式复制到测试模式。这是相当粗糙和准备好的，因为存储过程在遇到模式之间的任何差异时通常会崩溃，但它会提醒您任何未被告知的更改。
并提名某人成为监视架构更改的DBA？
就我而言，您的（关系数据库）做了两件事：1）保留数据和2）保存数据之间的关系。
保持数据是不是一种行为，所以你不会测试它
，并确保关系只是使用约束。很多的限制。到处都是。
这并不真正适合单元测试的范例。我会建议版本控制模式并限制对单个合格团队成员（如DBA或团队负责人）的写入访问权限，他们可以验证针对整个应用程序的任何请求更改。模式更改不应该随意进行。
难道你没有发现为代码编写的单元测试通常会发现数据库模式的任何问题吗？
这当然假设你的测试测试了一切。
我不得不做这种类型的事情，虽然不是在C＃中。首先，我根据Ode to Code (page 1 of 5)的讨论（还有现有的工具可以做类似的事情）构建了一个模式迁移工具。重要的是，我建立的迁移工具允许您指定要应用更改的数据库以及您想要应用的版本。然后，在测试第一种方法之后，无论何时我需要进行模式更改，我都会编写一个测试脚本，它将创建测试数据库，在我的目标更改脚本之前对版本进行版本更改，添加一些数据，应用更改脚本测试，并确认数据处于预期状态。
我的主要目标是确认在模式迁移过程中没有数据丢失或损坏，而不是特别检查模式是否处于特定状态。需要了解您的生产数据集，以便您可以为测试编写有代表性的样本数据。
这是值得商榷的，如果这应该被视为单元测试或集成测试。我倾向于认为它是集成测试，基于这样一个事实，即我不想在每次迭代我的代码时运行旧测试。无论你想怎么称呼它，我都觉得它是适合这种情况的有用工具。