在Postgres中使用繼承反對反模式（OTLT）

我知道「一個真正的查找表」的概念是一種反模式，通常不應該使用（參考網上許多許多文章）。但是，我想知道在Postgres中使用表繼承的情況是否仍然如此？在Postgres中使用繼承反對反模式（OTLT）

您永遠不會讀取或插入主查找表 - 它更多地作爲您的其他查找表的模板，您不會失去任何引用完整性（可能會獲得空間，否則會浪費在緩存塊中由於表中的數據量較大），並且在通過子表插入時，甚至不需要類型。

我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？

來源

2011-06-24 Mr Shoubs

我不確定我瞭解「父」，「實體參考」和「tstampdt」的用途。你可以編輯你的問題，並提供一些樣本數據，比如USPS縮寫的「查找表」中的狀態？ –

它們無關緊要。只是在我們的應用程序中的所有查找都有它們 –

關於數據庫設計有很多經驗法則，很多人堅持認爲「宗教戰爭」不是爲了捍衛它們，而沒有真正理解規則背後的原則。有一個非常真棒的線程here其中一個傢伙只是問爲什麼是OTLT如此邪惡？那裏有十幾個人說：「哦，夥計，這太糟糕了！」和一個人最終給出了幾個現實的底線。

底線是，如果你的表是相對靜態的，如果你沒有太多的用戶在同一時間點擊它們，如果你有控制誰/什麼/數據如何進入表，如果從從邏輯設計的角度來看，您仍然在建立單獨的查找表，那麼您可能會將OTLT視爲物理實現。

我一直在設計數據庫25年，在我看來，只要你明白這個決定的含義是什麼，你就可以隨意打破規則。在設計任何東西時總會有權衡。如果你睜大眼睛權衡利弊，那麼無論你做出什麼決定都應該是一個很好的決定。

假設你對各種附帶條件都沒有問題，比如確保你的OTLT不會成爲垃圾的熱點或沼澤，那麼在我看來，你提出的物理實現似乎介於「好」和「優雅」之間。

來源

2011-06-25 12:10:49

只是爲了增加這一點，READ，SNOMED和ICD標準*基於OTLT * – Paul

在Postgres中使用繼承反對反模式（OTLT）

回答

相關問題