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

我同意模块化设计是一条路要走。当我们为客户创建应用程序时,我们倾向于向他们销售我们已经构建的小部件集合。那么当顾客说 “我访问了网站X,我喜欢他们的小部件Y。你能将此添加到我的应用程序/网站吗?”

这是一件好事,客户a支付的小部件Z,我们可以出售给所有其他客户。诀窍是以这样一种方式构建这些小部件,使它们适合而不破坏当前的应用程序。

请查看此链接和注释中确定的来源。

MediaWiki Design - See notes at the bottom

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

如果我有选择的话,我可以让ORM工具创建脚本的基础,手动添加不属于ORM的细节(例如特殊索引、表空间、分区),还可以手动创建迁移脚本(当两个版本的完整脚本之间存在基于文本的差异时,这是非常直接的)。

所以我最后有三种剧本: 自动生成生成新数据库的脚本。 手动生成的脚本,执行相同的操作,但添加了一些与功能需求无关的细节。

如果我需要图表,我可以使用一些逆向工程从模式或对象模型的代码中创建它们。

我为每个模块模式保留单独的数据库构建脚本,并在注释中注意它们依赖于哪些其他模块。然后根据需要将模式添加到与应用程序对应的数据库中。使用普通索引而不是外键。我总是发现手工操作对于非常模块化的任务是最好的。

我使用的是PostgreSQL,我更喜欢自己编写db初始化(我希望拥有100%的控制权,SQL尽可能的显式)。我使用SchemaSpy生成ER图。

http://www.dbwrench.com/screenshots/xp_explorer.shtml

至于模块化设计,我不确定模式是否足够,imho模式使大脑更容易对数据如何关联做出假设,但它本身并没有使任何东西更模块化。请澄清您的需求,他们应该如何模块化。

grant DELETE, INSERT, UPDATE, SELECT on parentUser.table1 to childUser;
CREATE OR REPLACE SYNONYM childUser.table1 FOR parentUser.table1;

表1存在于parentUser架构中,但在执行上述查询后,可以从childUser访问此表。