使用继承来反 Postgres 中的反模式 (OTLT)

我知道“一个真正的查找表”的概念是一种反模式，通常不应该使用（参考网上的许多文章）。但是，我想知道当您在 Postgres 中使用表继承时，情况是否仍然如此？

您永远不会读取或插入主查找表 - 它更多地充当其他查找表的模板，您不会失去任何引用完整性（可能您会获得空间，否则由于数量较大，这些空间会浪费在缓存块中）表中的数据），并且当您通过子表插入时，您甚至不需要类型。

我的 OTLT 将具有所有查找表所需的以下列：

CREATE TABLE sl_lookupmaster
(
  lookupid bigserial NOT NULL,
  parent bigint,
  tstamptdt timestamp without time zone NOT NULL DEFAULT localtimestamp,
  description character varying(500) NOT NULL,
  entityref bigint NOT NULL,
  deleted boolean NOT NULL DEFAULT false,
  CONSTRAINT sl_lookupmaster_pkey PRIMARY KEY (lookupid)
)

然后你继承它。

人们怎么想，这还是一个设计错误吗？这还是 OTLT 吗？

关于数据库设计有很多经验法则，很多人在捍卫这些法则时坚持到了“宗教战争”的地步，而没有真正理解这些规则背后的原则。有一个非常棒的线程here http://www.dbforums.com/database-concepts-design/1619660-otlt-eav-design-why-do-people-hate.html一个人只是在问whyOTLT有这么邪恶吗？那里有十几个人说：“天哪，这太糟糕了！”一个人最终给出了一些现实的缺点。

最重要的是，如果您的表相对静态，如果没有太多用户同时访问它们，如果您可以控制谁/什么/如何数据进入表以及从逻辑设计的角度来看如果您仍在对单独的查找表进行建模，那么您可能可以使用 OTLT 作为物理实现。

我已经设计数据库 25 年了，在我看来，只要您了解该决定的影响，您就应该随意打破规则。设计任何东西总是需要权衡。如果你睁大眼睛做出权衡，那么你做出的任何决定都应该是一个好的决定。

假设您对各种附带条件都满意，例如确保您的 OTLT 不会成为垃圾热点或垃圾沼泽，那么在我看来，您提议的物理实现似乎介于“好”和“优雅”之间。