TL; DR - 我正在寻找关于多态关系表的最佳实践反馈。拥有一个没有外键约束的表（为关系的每一侧创建一个_id和_type列，以及关系类型的整体类型列）是否更好？或者更好的是拥有多个表，每个表一个一种可能的parent_type - relationship_type - child_type relationship？
我的（postgres 9.3）数据库中有几个表具有多态关系。特别是，Document可以授予User和Community类型对象的访问权限（其中Community有许多User个成员，因此授权社区的所有成员（权利），权利包括编辑，查看和评论。
现在，我将其建模为单一访问权限表：
CREATE TABLE edges (
id integer NOT NULL,
parent_id integer NOT NULL,
parent_type character varying(255) NOT NULL,
child_id integer NOT NULL,
child_type character varying(255) NOT NULL,
type character varying(255) NOT NULL,
created_at timestamp with time zone NOT NULL default CURRENT_TIMESTAMP
);
我在这个表上有五个主列（parent_type，parent_id，child_id，child_type，type）的复合索引。然而，自然地，我的许多不同类型的查询通常都不会触及主要索引 - 有时候我正在寻找哪些社区对此文档具有查看权限，更常见的是我正在查找哪些文档此社区拥有查看权限，而且我经常说，＆＃34;此用户或此用户所属的任何社区是否拥有此文档的查看权限＆＃34;。
我也无法真正利用我希望能够实现的任何外键约束。按照目前的情况，我不得不写一堆触发器来阻止我从ON DELETE CASCADE免费获得的行为。我也喜欢更强有力的保护措施（比如说）删除非空社区或孤立文件（创建根本没有人对它们拥有权利的文件），这对于我可以制作的一次性桌子来说更容易实施关于参照完整性的更强烈主张。
此时，我真的过早地进行了优化。我的整体数据库很小，我的用户群预计在未来五年内不会超过500。但是，我想从最佳实践的角度来看待这一点。
我可以将该单个表分解为大量较小的表（user_view_document，user_comment_document，community_view_document等 - 每种关系类型一个表）。当我第一次启动这个项目时，这是不可行的，因为我不知道系统中将有多少对象类型（这就是为什么有一个parent_type列）或者有多少权限类型也会在那里。
我在表格中也有其他边缘（用户可以同意/不同意文档，这也是一个优势），但这些查询很少见，我不介意将它们全部保存在一个表中（因为它可以更容易地计算文档在没有引用喜欢和同意和同情的情况下有多少反应，并且还可以更容易地构建新类型的用户 - ＆gt;文档反应和其他边缘），但我＆＃39;我认真考虑将权限关系拉出到自己的表中，主要是因为我的数据库现在所做的大部分工作都是使用该表来计算文档的访问权限。
我还可以单独留下这一点并查看更好的内存缓存计算值（我已经使用redis来存储每个用户的社区成员资格列表，因为我最终需要在每个单独的api查找中，因为我不得不使用它来计算访问权限）。
那么：这里有最佳实践吗？是否有好的书籍/博客/问题可以帮助我更好地优化我的查询和索引？