database - 使用继承在Postgres中反模式(OTLT)

我知道“一个真正的查找表”的概念是一个反模式，通常不应该使用（参考网上的许多文章）。但是，我想知道在postgres中使用表继承时是否仍然如此？
您永远不会读取或插入主查找表-它更像是其他查找表的模板，不会丢失任何ref完整性（可能由于表中的数据量较大，您获得的空间本来会浪费在缓存块中），并且在通过子表插入时，您甚至不需要类型。
我的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？

最佳答案

在数据库设计方面有很多经验法则，很多人在没有真正理解规则背后的原则的情况下，坚持到了为它们辩护的“宗教战争”的地步。有一条非常棒的线索，一个男人问为什么奥特特这么邪恶？那里有十几个人在说“哦，天哪，太糟糕了！”一个人最终给出了一些现实的反面。
归根结底，如果您的表是相对静态的，如果您没有太多的用户同时点击它们，如果您可以控制数据进入表中的人员/内容/方式，并且如果从逻辑设计的角度来看，您仍然在为单独的查找表建模，那么您可能可以将otlt作为一个物理实现来使用。
我已经设计数据库25年了，在我看来，只要你明白这个决定的含义，你就可以随意打破一条规则。在设计任何东西时总是有折衷的办法。如果你睁大眼睛权衡，那么无论你做什么决定都应该是个好决定。
假设你对各种各样的附加条件都满意，比如确保你的otlt不会成为垃圾的热点或泥潭，那么在我看来，你提议的物理实现似乎介于“好”和“优雅”之间。