在我开始的一项新工作中，我们有一个 Java 应用程序来处理核心业务逻辑中的大部分繁重工作，我们还有一个 Rails 应用程序当然可以处理该服务器的 Web 界面。两者都访问同一个数据库。
到目前为止，大部分重点都放在了 Java 应用程序上，因此，Rails 项目中没有迁移。用于更新共享数据库的 sql 在诸如 changes.sql 之类的文件中进行管理。
可以想象，这使得开发有些困难。
我最初的想法是结合 Java 项目和 Rails 应用程序的代码库，因为那里存在依赖关系，并在源代码中管理那个 SQL 文件。但是，我想我会在这里询问是否有其他人在一定程度上成功地解决了这个问题。
一种方法是使用 rails 迁移工具，为数据库生成 DDL 文件并使用 Hibernate 更新与特定数据库实体相关的 Java 对象。您并没有真正说明如何在 Java 端管理数据库更改或是否使用 ORM，但您当然可以通过一些工作使两者同步。
或者您可以反过来，让 Java 定义控制 Rails 端的更改。
我认为成功做到这一点的关键是选择两个平台之一作为您的“主要数据库建模器”，并开发将该模型迁移到另一个平台的过程。试图允许两者都进行更改只会让人头疼。
We have a similar project structure: shared database with both java and rails applications as clients. I advocated and got buy-in to use the rails migration mechanism for handling database changes. It takes a bit of rails advocacy, and some willingness to help but the java team is also writing their own migrations.
We have some cases where we use stored procedures and database specific column types, so we changed the rails environment.rb to use sql for creating the test database.
# Use SQL instead of Active Record's schema dumper when creating the test database.
# This is necessary if your schema can't be completely dumped by the schema dumper,
# like if you have constraints or database-specific column types
config.active_record.schema_format = :sql
On the plus side managing the sql with migrations makes rails testing and setup clean for you. The downside is that some of the migration files are just not that pretty (e.g., you can't use the migration DSL to generate stored procedures so you have these execute %{blah } in your migrations).
Just remember to keep communication lines open beteen the teams. I like the fact that "cap production deploy:migrations" makes updating the production database dead simple.
谢谢史蒂夫
在 Java 方面，他们使用的是 Hibernate，但有一个手动 SQL 更新过程。
我同意，它应该是一个或另一个。我越想，添加另一个应用程序/模块/代码库来管理数据库绝对是错误的想法。
谢谢