python - 有哪些策略可以在没有 DBA 的情况下与开发人员团队一起维护通用数据库模式？

Question

我很好奇其他人如何在没有 DBA 的情况下解决许多(10 多个)开发人员维护和同步数据库更改的问题？我的意思是，基本上，如果有人想对数据库进行更改，那么执行此操作的一些策略是什么？ (即我已经创建了一个“汽车”模型，现在我想将适当的 DDL 应用到数据库等。)

我们主要是一家 Python 商店，我们的 ORM 是 SQLAlchemy。以前，我们编写模型的方式是使用我们的 ORM 创建模型，但我们最近放弃了这种方式，因为:

• 我们无法使用 ORM 跟踪更改
• ORM 的状态与数据库不同步(例如，许多差异主要与索引和唯一约束有关)
• 除非开发人员通过电子邮件向团队记录数据库更改，否则无法审核数据库更改。

我们对这个问题的解决方案基本上是有一个“看门人”个人检查数据库中的每个更改并将所有已接受的数据库更改应用到 accepted_db_changes.sql 文件，从而需要的开发人员进行任何数据库更改将他们的请求放入 proposed_db_changes.sql 文件中。我们 checkin 这个文件，当它更新时，我们都将更改应用到我们开发机器上的个人数据库。我们不在模型上创建索引或约束，它们明确应用于数据库。

我想知道维护数据库模式的一些策略是什么，我们的策略是否合理。

谢谢!

Answer 1

解决方案是管理性的，而不是技术性的:)

一般规则很简单，项目中应该只有树状依赖项:- 应该始终有一个主模式源，与版本控制中的项目源代码一起存储- 每次更新主源时，受主源更改影响的所有内容都应自动重新生成，永远不允许手动干预，如果自动生成不起作用——修复主源或生成器，不要手动更新源代码- 所有重新生成都应由更新主源的同一个人执行，包括主源更改在内的所有更改都应视为单个事务(单个源控制提交，每个受影响环境的单个构建/部署，包括数据库更新)

强制执行后，这会提供 100% 可靠的结果。

基本上有 3 种可能的主源选择1)数据库元数据，源是在数据库更新后通过连接到实时数据库的一些工具生成的2)源代码，一些工具从源代码生成SQL方案，以特殊方式注释，然后在数据库上运行SQL3)DDL，SQL schema和源代码都是由一些工具生成的4) 使用了一些其他描述(比如由生成 SQL 模式和源代码的特殊 Perl 脚本读取的文本文件)

1、2、3 同样好，前提是您需要的工具存在且价格不贵4 是一种通用方法，但它应该从项目的一开始就应用，并且需要用一种奇怪的语言维护几千行代码