后端依赖数据库的存储库管理，无需使用 ORM 工具
repository management for backend relying on database without using an ORM tool
大多数情况下，在使用数据库设置后端项目时，我都会使用 ORM 工具来处理数据库内容。因此，数据库模式和迁移与后端代码耦合，我可以将其保存在我的后端存储库中。
现在我正在创建仅依赖于一种数据库类型的多个项目，并且必须使用纯 SQL。
我想了解处理额外 "database project" 的最佳做法。含义数据库 - 后端 - 前端。我应该将数据库方案放入自己的存储库中吗？然后我也可以将 SQL 脚本如 MigrationFrom1To2 放入此存储库中。
我想到的问题是，当与许多开发人员一起开发数据库和后端项目时，如何使两个项目保持同步？假设有一个对后端代码的拉取请求，该请求需要一个尚不存在的新数据库 table。然后你将不得不等待数据库存储库也实现该功能（添加 link 导致另一个存储库的问题）。通过这样做，每个后端开发人员都必须拉取最新的数据库迁移脚本来更新他自己的本地数据库，因此他必须在后端工作之前检查新的数据库迁移。
目前我知道如何使用 ORM 管理项目，但如果有人可以解释如何使用普通 SQL 管理项目（一个数据库就可以），那就太好了。如果有帮助，我正在使用 MariaDb 和 .NET Core。特别是涉及到自动构建和 Docker（使用 Github 动作或其他东西）。
许多应用程序连接到同一个数据库通常不是一个好主意，这是人们转向微服务的主要原因之一。所以他们有数据隔离，一个服务与另一个服务数据库无关。
如果您有一个大型解决方案来处理许多项目，我建议您使用
DbUp 是一个 .NET 库，可帮助您将更改部署到 SQL 服务器数据库。它跟踪哪些 SQL 脚本已经 运行，以及 运行 更新数据库所需的更改脚本。
它不是ORM，它使用纯SQL。您在代码中创建了一个 SQL 脚本列表，它也是源代码管理的一部分，每次启动应用程序时，您都会检查是否应用了所有迁移，如果没有应用最后的更改。
迁移检查和数据库更新可以自动化
- 如part of the CI/CD pipelines.
- 作为应用程序中的启动任务，运行每次应用程序启动时。您可以在 Andrew Lock's 博客中找到有关如何设置启动任务的示例。
在多个项目中，我们遇到了与您相同的情况，以下是我们的解决方法。
情况
一个数据库用于多个相关的事物。承包商正在开发依赖于数据库的应用程序子集。员工正在同一数据库上处理应用程序的另一个子集。 DBA 负责迁移。
存储库
我们有 2 个存储库 - 一个用于应用程序开发，另一个用于数据库。合同和员工在应用程序存储库中编写代码。数据库更改发生在数据库存储库中。 DBA 正在迁移数据库存储库。应用变更控制团队正在从应用存储库部署代码。 DBA 和应用变更控制团队充分协调，以正确的方式部署正确的东西。
B运行清攻略
承包商在应用程序和数据库存储库上创建了一个功能 b运行ch（例如 user-preferences）。对数据库的更改将进入数据库存储库。对应用程序的更改将进入应用程序存储库。一旦编写了足够多的依赖于他们的数据库更改的代码，他们就会标记发布并将其推出。变更管理和 DBA 一起审查了两个存储库中 user-preferences b运行ch 的拉取请求，以确保他们可以正确部署，然后将 b运行ches 合并到 master 并完成他们的发布过程。功能标志在受控环境中打开和关闭，以确保没有 post-production 问题。团队成员在一天中多次合并。这种方法效果很好。您可能会注意到，CI/CD 并不是完全自动化的。团队互相讨论他们对 DB 所做的更改，因此每个人都知道会发生什么。
T运行k基础开发
在不同的情况下，我们决定在应用程序和数据库存储库中创建本地 b运行ch。我们将测试代码和数据库更改并尽快干净地合并。在经过 QA、pre-production 检查等之后，DBA 和变更管理团队每天都会部署到生产中。令人惊讶的是，我们没有那么多冲突，而且我们遇到的冲突很容易解决。我们强调创建数据库更改并在开发人员测试他们的理论后立即将其推向掌握。数据库更改先于代码。
就像功能标志一样，开发人员在允许用户交互之前检查了他们的数据库依赖项。如果不知何故，数据库更改了他们所依赖的代码，则会显示一条优雅的消息，并且最终会发送一封电子邮件，供更改管理人员审查依赖项。同样，令人惊讶的是，事情进展顺利。
更复杂的例子
一家受监管的公司有多个承包团队，一些从事敏捷开发，一些采用瀑布式开发，一些使用他们自己编造的开发方法。公司的员工有多个团队，与不同的承包商有着相同的差异。他们都必须一起工作来创建功能、解决问题等。听起来很混乱，对吧？他们创建了一个每日 CAB 会议——CAB 代表变更批准委员会。每个团队都会花 5 分钟时间向 CAB 说明他们打算将什么推向生产环境以及他们的依赖项。有不同的存储库和版本控制系统。
允许进行非常小的更改并将其投入生产。大的改变会大张旗鼓地成批进行。变更管理团队从各种 repos/version 控制系统收集代码，在他们的 sim（模拟）环境中播放（首先是数据库，然后是应用程序更改），然后计划用于生产。大的变化是持久的 b运行ches，每晚都会更新小的变化。大改要出的月份，小改要停几天。大的变化会消失，然后小的变化会恢复。 F运行kly，它离完美还差得很远，但只要有 2 个 FTE 像鹰一样观察部署，它就会起作用。
两家公司的共同点是，应用程序开发人员的功能已被标记，并且 运行 有一个 pre-flight 清单，以确保所有依赖项都已到位，以确保其功能 运行 成功。这样，如果遗漏了什么，错误就会被记录下来，并且用户会被优雅地告知 do/who 要调用什么。
大多数情况下，在使用数据库设置后端项目时，我都会使用 ORM 工具来处理数据库内容。因此，数据库模式和迁移与后端代码耦合，我可以将其保存在我的后端存储库中。
现在我正在创建仅依赖于一种数据库类型的多个项目，并且必须使用纯 SQL。
我想了解处理额外 "database project" 的最佳做法。含义数据库 - 后端 - 前端。我应该将数据库方案放入自己的存储库中吗？然后我也可以将 SQL 脚本如 MigrationFrom1To2 放入此存储库中。
我想到的问题是，当与许多开发人员一起开发数据库和后端项目时，如何使两个项目保持同步？假设有一个对后端代码的拉取请求，该请求需要一个尚不存在的新数据库 table。然后你将不得不等待数据库存储库也实现该功能（添加 link 导致另一个存储库的问题）。通过这样做，每个后端开发人员都必须拉取最新的数据库迁移脚本来更新他自己的本地数据库，因此他必须在后端工作之前检查新的数据库迁移。
目前我知道如何使用 ORM 管理项目，但如果有人可以解释如何使用普通 SQL 管理项目（一个数据库就可以），那就太好了。如果有帮助，我正在使用 MariaDb 和 .NET Core。特别是涉及到自动构建和 Docker（使用 Github 动作或其他东西）。
许多应用程序连接到同一个数据库通常不是一个好主意，这是人们转向微服务的主要原因之一。所以他们有数据隔离，一个服务与另一个服务数据库无关。
如果您有一个大型解决方案来处理许多项目，我建议您使用
DbUp 是一个 .NET 库，可帮助您将更改部署到 SQL 服务器数据库。它跟踪哪些 SQL 脚本已经 运行，以及 运行 更新数据库所需的更改脚本。
它不是ORM，它使用纯SQL。您在代码中创建了一个 SQL 脚本列表，它也是源代码管理的一部分，每次启动应用程序时，您都会检查是否应用了所有迁移，如果没有应用最后的更改。
迁移检查和数据库更新可以自动化
- 如part of the CI/CD pipelines.
- 作为应用程序中的启动任务，运行每次应用程序启动时。您可以在 Andrew Lock's 博客中找到有关如何设置启动任务的示例。
在多个项目中，我们遇到了与您相同的情况，以下是我们的解决方法。
情况
一个数据库用于多个相关的事物。承包商正在开发依赖于数据库的应用程序子集。员工正在同一数据库上处理应用程序的另一个子集。 DBA 负责迁移。
存储库
我们有 2 个存储库 - 一个用于应用程序开发，另一个用于数据库。合同和员工在应用程序存储库中编写代码。数据库更改发生在数据库存储库中。 DBA 正在迁移数据库存储库。应用变更控制团队正在从应用存储库部署代码。 DBA 和应用变更控制团队充分协调，以正确的方式部署正确的东西。
B运行清攻略
承包商在应用程序和数据库存储库上创建了一个功能 b运行ch（例如 user-preferences）。对数据库的更改将进入数据库存储库。对应用程序的更改将进入应用程序存储库。一旦编写了足够多的依赖于他们的数据库更改的代码，他们就会标记发布并将其推出。变更管理和 DBA 一起审查了两个存储库中 user-preferences b运行ch 的拉取请求，以确保他们可以正确部署，然后将 b运行ches 合并到 master 并完成他们的发布过程。功能标志在受控环境中打开和关闭，以确保没有 post-production 问题。团队成员在一天中多次合并。这种方法效果很好。您可能会注意到，CI/CD 并不是完全自动化的。团队互相讨论他们对 DB 所做的更改，因此每个人都知道会发生什么。
T运行k基础开发
在不同的情况下，我们决定在应用程序和数据库存储库中创建本地 b运行ch。我们将测试代码和数据库更改并尽快干净地合并。在经过 QA、pre-production 检查等之后，DBA 和变更管理团队每天都会部署到生产中。令人惊讶的是，我们没有那么多冲突，而且我们遇到的冲突很容易解决。我们强调创建数据库更改并在开发人员测试他们的理论后立即将其推向掌握。数据库更改先于代码。
就像功能标志一样，开发人员在允许用户交互之前检查了他们的数据库依赖项。如果不知何故，数据库更改了他们所依赖的代码，则会显示一条优雅的消息，并且最终会发送一封电子邮件，供更改管理人员审查依赖项。同样，令人惊讶的是，事情进展顺利。
更复杂的例子
一家受监管的公司有多个承包团队，一些从事敏捷开发，一些采用瀑布式开发，一些使用他们自己编造的开发方法。公司的员工有多个团队，与不同的承包商有着相同的差异。他们都必须一起工作来创建功能、解决问题等。听起来很混乱，对吧？他们创建了一个每日 CAB 会议——CAB 代表变更批准委员会。每个团队都会花 5 分钟时间向 CAB 说明他们打算将什么推向生产环境以及他们的依赖项。有不同的存储库和版本控制系统。
允许进行非常小的更改并将其投入生产。大的改变会大张旗鼓地成批进行。变更管理团队从各种 repos/version 控制系统收集代码，在他们的 sim（模拟）环境中播放（首先是数据库，然后是应用程序更改），然后计划用于生产。大的变化是持久的 b运行ches，每晚都会更新小的变化。大改要出的月份，小改要停几天。大的变化会消失，然后小的变化会恢复。 F运行kly，它离完美还差得很远，但只要有 2 个 FTE 像鹰一样观察部署，它就会起作用。
两家公司的共同点是，应用程序开发人员的功能已被标记，并且 运行 有一个 pre-flight 清单，以确保所有依赖项都已到位，以确保其功能 运行 成功。这样，如果遗漏了什么，错误就会被记录下来，并且用户会被优雅地告知 do/who 要调用什么。