我有一个填充SQL Server数据库的服务。该服务是用nodejs编写的。
很快我将不得不创建一个显示数据库数据的网站。然后创建一个单独的网站，一个数据库管理面板。
很快就会增加与数据库交互的更多服务。新服务可能不会使用相同的语言或平台。
目前，数据库架构包含在与服务代码捆绑在一起的SQL文件中。单元测试使用该文件在每次测试之前设置测试数据库。
2个，3个或更多项目共享数据库架构的最佳方法是什么？
我想确保如果我更改数据库，我不会忘记更新其中一个项目或其测试。
什么是行业最佳实践？数据库模式应该在一个单独的模块中，作为依赖项保存吗？如何解决使用不同语言的问题？
答案 0 :(得分：1)
这是一个复杂的问题，我不确定是否有一个最好的答案。
你面临的问题是耦合问题 - 你的解决方案中有一个人工制品，它是其他几个人工制品的依赖关系。软件中最古老的架构原则之一是减少耦合 - 它会导致错误，开发速度变慢，以及难以修改的代码。
有许多方法可以减少软件设计中的耦合。经典的答案是引入接口和依赖注入;这对数据库来说显然不实用。
“最干净”的方式是通过API访问您的数据库。您可以使用版本控制来允许多个应用程序管理该依赖项 - 应用程序A是针对API的1.0版进行编码的，并且您保证不会更改该版本（或者至少不会没有弃用通知）。这确实引入了大量额外的工作，以及潜在的性能挑战。
更实用的解决方案是坚持所有环境的自动部署机制，并从中心位置检索数据库架构，并坚持所有应用程序都包含一组集成测试来执行所有数据库功能。您可以通过VM映像分发您的开发和测试数据库，例如，您的模式具有“只读”状态。
我使用各种技术完成了这项工作。第一步是创建一个流程，将数据库转换为可在源代码存储库中管理的文本文件，并回放以创建工作数据库。 Here's一个SO问题，有很多关于如何做到这一点的信息。
在数据库受版本控制之后，您可以决定如何分发数据库 - 要么是要求项目签出数据库并自行构建，要么是停靠者映像，虚拟机等等。
您依赖于您的应用程序来做正确的事情 - 它不是由技术特性强制执行 - 但您不必为您的解决方案引入重要的新层。