在我开始的一项新工作中，我们有一个Java应用程序来处理核心业务逻辑中的大部分繁重工作，而且我们还有一个Rails应用程序，当然它可以处理网页界面到这个服务器。这两个访问相同的数据库。管理Rails和Java项目之间的数据库更改
到目前为止，大部分工作都集中在Java应用程序上，因此Rails项目中没有任何迁移。更新共享数据库的sql在像change.sql这样的文件中进行管理。
正如你所想象的那样，这使得开发起来有些困难。
我最初的想法是将Java项目和Rails应用程序的代码库组合起来，因为那里存在依赖关系，并且要在源代码中管理该SQL文件。然而，我想我会问在这里看看是否有其他人在某种程度上成功解决了这个问题。
一种方法是使用rails迁移工具，为数据库生成DDL文件并使用Hibernate更新与特定数据库实体相关的Java对象。你并没有真正地说过你如何管理Java端的数据库更改，或者你是否使用ORM，但你可以通过一些工作来同步这两者。
或者你也可以换个角度让Java定义控制Rails方面的变化。
我认为成功完成这一任务的关键是选择两个平台中的一个作为“主数据库建模器”，并开发将该模型迁移到其他平台的过程。试图允许两者的变化只会导致头痛。
感谢史蒂夫
在Java方面，他们使用的休眠模式，但有手动SQL更新过程。
我同意，它应该是一个或另一个。我考虑的越多，添加另一个应用程序/模块/代码库来管理数据库肯定是错误的想法。
感谢
我们有一个类似的项目结构：共享数据库与Java和Rails应用作为客户端。我主张并得到了支持使用rails迁移机制来处理数据库更改。它需要一些铁轨支持，并且有一些愿意提供帮助，但是Java团队也正在编写他们自己的迁移。
我们有一些使用存储过程和数据库特定列类型的情况，所以我们更改了rails environment.rb以使用sql创建测试数据库。
# 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
另一方面，使用迁移来管理sql使得rails测试和设置变得干净。缺点是某些迁移文件不够漂亮（例如，您不能使用迁移DSL来生成存储过程，因此您在迁移时执行了这些执行％{blah}）。
只要记住要保持沟通线路开放队伍。我喜欢“cap production deploy：migrations”这一事实，使得更新生产数据库变得非常简单。