代码之家  ›  专栏  ›  技术社区  ›  Jedidja

如何(单元)测试数据库架构?

  •  10
  • Jedidja  · 技术社区  · 17 年前

    当有很多人在一个项目上工作,所有人都可以修改数据库模式时,最简单的方法是什么?到目前为止,我们的主要建议是为每个表编写测试,以验证列名、约束等。

    还有人做过类似的/更简单的事情吗?如果这真的有什么不同的话,我们在SQL Server上使用C。

    更新:

    • 我们正在处理的项目部分使用SSIS包来完成大部分工作,因此很少有C代码来再次编写单元测试。
    6 回复  |  直到 17 年前
        1
  •  4
  •   Chris Simpson    17 年前

    一个可能的答案是使用Visual Studio开发数据库,并将模式与其余代码一起保持在源代码控制中。这可以让你看到差异,你得到谁改变了什么的历史。

        2
  •  2
  •   George Mauer    17 年前

    就我而言,您的(关系)数据库做了两件事:1)保存数据,2)保存数据之间的关系。

    保存数据不是一种行为,因此您不会对其进行测试

    为了确保关系只使用约束。很多限制。到处都是。

        3
  •  1
  •   Mark Tozzi    15 年前

    我以前也做过这种事,虽然不是用C。首先,我根据在 Ode to Code (page 1 of 5)

    我的主要目标是确认模式迁移期间没有数据丢失或损坏,而不是特别检查模式是否处于特定状态。需要对您的生产数据集有很好的了解,因此您可以为测试编写具有代表性的示例数据。

    这是否应该被视为单元测试或集成测试是有争议的。我倾向于考虑I t集成测试,因为我不想每次迭代代码时都运行旧的测试。不管你怎么称呼它,我发现它是解决这种情况的有用工具。

        4
  •  1
  •   David Price    6 年前

    这是一个老问题,但似乎人们仍在这里降落。所以到目前为止我发现的最好的工具是红门的“SQL测试”。它允许您创建作为事务运行的脚本。允许您运行“沙盒”查询以检查数据库的状态。

        5
  •  0
  •   James Piggot    17 年前

    这是个有趣的问题!有很多工具可以测试存储过程,但不能测试数据库模式。

    您不觉得为代码编写的单元测试通常会发现数据库模式有任何问题吗?

    并指定一个人作为DBA来监视对模式的更改?

        6
  •  0
  •   Peter    17 年前

    这并不真正符合单元测试范式。我建议对模式进行版本控制,并将写入权限限制在一个合格的团队成员(如DBA或团队领导)身上,他们可以针对整个应用程序验证任何请求的更改。架构更改不应随意进行。

        7
  •  0
  •   Marvin Marvin    17 年前

    您不觉得为代码编写的单元测试通常会发现数据库模式有任何问题吗?