Question

我知道“一个真正的查找表”的概念是反模式，通常不应该使用（在网上引用很多文章）。但是，我想知道在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吗？

Answer 1

有很多关于数据库设计的经验法则，很多人坚持要求“宗教战争”而不是真正理解规则背后的原则。有一个非常棒的线程here，其中一个人只是问为什么是OTLT如此邪恶？那里有十几个人说“噢，伙计，这很糟糕！”一个人最终给了一些现实的下方。

最重要的是，如果您的表格相对静态，如果您没有太多用户同时点击它们，如果您可以控制数据进入表格的人/方式/方式以及来自逻辑设计透视图你仍在为不同的查找表建模，那么你可以将OTLT作为一个物理实现。

我一直在设计数据库25年，在我看来，只要你明白这个决定的含义是什么，你就应该随意打破规则。在设计任何东西时总会有权衡。如果你睁大眼睛做出权衡，那么无论你做出何种决定都应该是一个好的决定。

假设你对各种条款都没问题，比如确保你的OTLT不会成为垃圾邮件的热点或陷阱，那么你认为你提出的物理实现似乎介于“好”和“优雅”之间。

使用继承来反对Postgres中的反模式（OTLT）

1 个答案: