我不确定我是否理解你问题的所有细微之处，特别是关于使用SQLite vs PostgreSQL的评论。如果这将是一个多个DBMS系统，那么使用多个系统进行测试是好的；如果这将是单个DBMS系统，则与多个DBMS一起工作将使生活变得毫无意义。

此外，您提到需要跟踪数据库中的模式更改...这是将模式更改的信息单独存储于DBMS自身的系统目录之外，还是您真的意味着您想要跟踪数据库的模式更改（使用数据库外的某种工具，比如VCS）？

您还谈到了跟踪DB数据更改，我理解为指数据库表中的数据。同样，我不清楚您是否在考虑从数据库中转储数据，涵盖了一天之前和现在存在的差异，或者其他什么。

这些问题可能是你四个多小时没有得到回应的原因。

当你谈论一个简单的包装器时，你并不是在谈论我所谓的简单。它必须解析任意的 SQL，确定其中是否有任何特定于 DBMS 的内容，然后应用重写规则。这是一项非常困难的任务。将包装器调用在正确的位置可能也很困难，这取决于你使用的用于访问 DBMS 的 API 集，以及其他一些因素。

还有什么？

• Use the same DBMS in both production and development?
• Tracking just schema changes is non-trivial. You need to track the essence of the schema (such as table name, column names, etc) and not the accidence (yeah, I was rereading Brooks "No Silver Bullet" earlier) such as the TabID (which might vary without the schema being materially different). However, an analysis would tell you whether the schema is different.
• Tracking the data changes, independent of schema changes, is also non-trivial. In general, the volume of such data is large. You may be able to deal with a full archive or a full unload or export of the database - but ensuring that the data is presented in the same sequence each time may require some care on your part. If you don t ensure the correct sequencing, the VCS will be recording huge changes due to ordering differences.

以上都归结为令人生畏的“这要看情况”答案。它取决于：

• Your DBMS
• Your database size
• The volatility of your schema
• The volatility of your data

幸运的是，这只在某种程度上取决于您的版本控制系统或平台。

如果我理解正确，你想能够跟踪模式和数据更改。

这实际上是两件非常不同的事情 -

• Schema changes - this is discussed in several other questions (here, here and here). The main take from the answers to these questions is that you can either dump your schema to SQL files and track them with your regular source control (git, svn, etc.) or you can use a DB specific SW (red-gate, dbmaestro). However, this won t allow you to completely re-create an identical copy of a DB on another server. Which brings me to -
• Data changes - This is harder, because (like @jonathan wrote) it s difficult track the changes the DB makes to it s files. I suggest you checkout OffScale DataGrove. DataGrove tracks changes to the entire DB (structure+data). You can tag versions in any point in time, and return to older states of the DB with a simple command. It also allows you to create virtual, separate, copies of the same database so each team member can have his own separate DB. All the virtual copies are tracked into the same repository so it s super-easy to revert your DB to someone else s version (what you called "git-pull").

免责声明 - 我在OffScale工作 :-)