我正在开发可以部分从模块构建的应用程序。例如，我将能够开发一些包含“论坛”、“博客”、“画廊”等模块的在线社区。
目前我有一个大型数据库 ERM，其中包含具有外键连接的所有模块的所有表，我正在使用 dbwrench 来构建这个 ERM。但是，我对这种方法不是很满意。我想有一个 ERM 设计师，它可以以面向模块的方式工作。我想为每个模块将数据库表保存在一个单独的模式文件中，但在这些不同的模式之间保留外键引用。
但是，我找不到任何支持这一点的工具——这是错误的方法还是你如何设计“模块化 ERM”/模块化数据库方案？
谢谢！
我同意模块化设计是要走的路。当我们为客户创建应用程序时，我们倾向于向他们出售我们已经构建的小部件集合。那么当客户说“我访问了网站 X 并且我喜欢他们的小部件 Y。你可以将它添加到我的应用程序/网站中吗？”时会发生什么？
这是一件好事，客户 A 为小部件 Z 付费，然后我们可以将其出售给所有其他客户。诀窍是以这样的方式构建这些小部件，以便它们适合而不破坏当前应用程序。
查看此链接和注释中确定的来源。
我绝对相信，这是正确的做法。不幸的是，数据库社区尚未接受模块化设计、敏捷软件开发等新概念。
如果我有选择，我让 ORM 工具创建脚本的基础，并手动添加不属于 ORM 的详细信息（例如特殊索引、表空间、分区），还手动创建迁移脚本（这很简单当你有基于文本的差异时，在两个版本的完整脚本之间转发。
所以我最终得到了三种脚本：自动生成的脚本，生成一个新的数据库。手动生成的脚本执行相同的操作，但添加了一些与功能要求无关的细节。一组迁移脚本，逐步将数据库从一个版本移动到下一个版本。
我还有一堆测试，它们使用这些脚本的组合创建各种模式并进行比较。
如果我需要图表，我会使用一些逆向工程从模式或对象模型的代码中创建这些图表。
我为每个模块模式保留单独的数据库构建脚本，并在注释中注明它们依赖的其他模块。然后，我根据需要将架构添加到与应用程序对应的数据库中。使用普通索引而不是外键。我一直发现手动操作最适合高度模块化的任务。
我更喜欢使用模式。这是封装关注区域的自然方式（无论是模块的模式还是覆盖信息区域的模式）。
我正在使用 PostgreSQL，我更喜欢自己编写数据库启动（我希望拥有 100% 的控制权，并且 SQL 尽可能明确。）。我使用 SchemaSpy 生成 ER 图。我对多个模式和跨模式的外键没有任何问题 - 不确定它在 MySQL 中是如何工作的。
我不熟悉您提到的工具，但是，屏幕截图似乎显示它们支持模式。可能值得再次检查。 http://www.dbwrench.com/screenshots/xp_explorer.shtml
至于模块化设计，我不确定模式是否足够，恕我直言，模式使大脑更容易对数据的关联方式做出假设，它本身并没有使任何东西更加模块化。请阐明您对它们应该如何模块化的需求。
我在 oracle 数据库中使用了模块化。您可以通过 SYNONYM 访问外键、视图、表、函数、存储过程。您必须执行以下两个查询才能在父模式的子模式中生成 SYNONYM。
grant DELETE, INSERT, UPDATE, SELECT on parentUser.table1 to childUser;
CREATE OR REPLACE SYNONYM childUser.table1 FOR parentUser.table1;
table1 存在于 parentUser 架构中，但执行上述查询后，您可以从 childUser 访问此表。