在一个开发团队而没有DBA的情况下，维护一个公共数据库模式的策略是什么？

Question

我很好奇，在没有DBA的情况下，其他人是如何处理在许多（10多个）开发人员之间维护和同步数据库更改的问题的？我的意思是，基本上，如果有人想对数据库进行更改，有什么策略可以这样做？（例如，我已经创建了一个“Car”模型，现在我想对数据库应用适当的DDL等等）

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

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

我们解决这个问题的方法是让一个“看门人”来检查数据库中的每一个更改，并将所有接受的数据库更改应用到accepted_db_changes.sql文件中，因此需要对数据库进行任何更改的开发人员将其请求放入proposed_db_changes.sql文件中。我们签入这个文件，当它更新时，我们都会将更改应用到我们开发机器上的个人数据库中。我们不在模型上创建索引或约束，它们显式地应用于数据库。在

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

谢谢！在

Answer 1

你试过SQLalchemy Migrate工具吗？在

它们是专门为自动迁移数据库设计更改而设计的。在

Answer 2

所以我假设你直接在物理数据库上设计你的数据库是正确的吗？我在很多年前就这样做了，但是结果数据库的质量非常差。如果你使用一个建模工具（我个人认为Sybase pdesigner仍然是最好的，但是看看周围），每个人都可以对模型进行更改，只需根据需要同步他们的本地数据库（它还将接收文档任务）。所以，在re bobah的帖子中，master是pdesigner模型，而不是物理db。在

您的accepted_db_changes.sql文件是一个庞大的变更脚本列表吗？我不确定我是否喜欢更改文件名等。鉴于两个db版本之间的区别是alter脚本的顺序列表，那么下面这样的模型怎么样：

Ver1 (folder)
  Change 1-1.sql
  Change 1-2.sql
  Change 1-3.sql
Ver2 (folder)
  Change 2-1.sql
  Change 2-2.sql
  Change 2-3.sql

在提交之前，每个更改（新文件）都将被审阅。在

一般规则应该是有意识地在您的开发环境中尽可能多地自动化数据库部署；我们在这项工作上取得了可观的投资回报。您可以使用像redgate这样的工具来生成ddl（它有一个api，但不确定它是否与SQLAlchemy一起工作）。在IMO中，DB的更改应该是微不足道的，如果您发现它们阻塞了，那么看看您可以自动执行哪些操作。在

Answer 3

解决方案更具管理性而非技术性：）

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

实施后，结果100%可靠。在

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

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