数据库模式设计工具 / 模块化数据库设计

Question

我正在开发可以部分由模块构建的应用程序。例如，我可以开发包含'论坛'、'博客'、'画廊'等模块的在线社区。

目前，我有一个大型数据库ERM，其中包含所有模块的表及其外键连接，并且我正在使用dbwrench构建此ERM。然而，我对这种方法并不满意。我想要一个可按模块设计的ERM设计器。我想将数据库表保存在每个模块的单独模式文件中，但保留这些不同模式之间的外键引用。

然而，我没有找到任何支持这种方式的工具--这是错误的方式吗？或者您如何设计“模块化ERM”/模块化数据库方案？

谢谢！

- harald

Answer 1

我认为模块化设计是正确的方式。当我们为客户创建应用程序时，我们倾向于出售我们已经构建的小部件集合。因此，当客户说“我访问了网站X，我喜欢他们的小部件Y。你能将它添加到我的应用程序/网站中吗？”时会发生什么？

这是好事，客户A支付小部件Z的费用，然后我们可以将其销售给所有其他客户。关键在于以这种方式构建这些小部件，使它们适合当前应用程序而不会破坏它。

请查看此链接以及注释中标识的来源：MediaWiki Design - 请参阅底部的注释。

- Michael Riley - AKA Gunny

---

你好，这是你发布的正确链接吗？我不确定你指的是哪些笔记。谢谢！ - aurora

是的，请在图像下方查看“SOURCE”参考：由我创建，使用Windows上的DB Designer 4.0.5.6 Beta，但也包含来自MediaWiki的tables.sql文件和MediaWiki.org上的表描述的信息（请参见：mw:Manual:Database layout）。 - Michael Riley - AKA Gunny

Answer 2

我完全相信，这是正确的方法。不幸的是，数据库社区尚未接受诸如模块化设计、敏捷软件开发等新概念。

如果可以选择，我会让ORM工具创建脚本的基础，并手动添加一些不属于ORM的细节（例如特殊索引、表空间、分区），并手动创建迁移脚本（当您拥有两个版本中完整脚本之间的文本差异时，这是非常直观的）。

因此，我最终得到了三种类型的脚本： 自动生成的脚本，用于生成新数据库。 手动生成的脚本，执行同样的操作，但增加了一些无关功能要求的详细信息。 一组迁移脚本，逐步将数据库从一个版本移动到下一个版本。

我还有一堆测试，使用这些脚本的组合创建各种模式，并进行比较。

如果需要图表，我会从模式或对象模型的代码中创建它们，使用一些反向工程技术。

- Jens Schauder

Answer 3

我更喜欢使用模式。这是一种自然的方式来封装一个关注领域（无论是为模块创建模式，还是为信息领域创建模式）。

我正在使用PostgreSQL，并且我更喜欢自己编写数据库初始化（我想要100％的控制权，而SQL就像它得到的那样明确）。我使用SchemaSpy来生成ER图。 我在多个模式和跨模式的外键方面没有任何问题-不确定MySQL如何处理。

我不熟悉您提到的工具，但是屏幕截图似乎显示它们支持模式。重新检查一下可能会有好处。 http://www.dbwrench.com/screenshots/xp_explorer.shtml

至于模块化设计，我不确定模式是否足够，我认为模式使大脑更容易做出关于数据关系的假设，但本质上并未使任何内容更加模块化。请明确您对模块化设计的需求。

- user348466

---

谢谢你的回答，我会查看你关于模式的建议！ - aurora

Answer 4

我为每个模块的架构保留单独的数据库构建脚本，并在注释中记录它们依赖的其他模块。然后根据需要将架构添加到相应的应用程序中。使用普通索引而不是外键。我始终发现对于极其模块化的任务，手动完成事情是最好的。

- Fire Crow

Answer 5

我在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 访问此表。

- user3190254