継承を使用したPostgresのアンチパターン（OTLT）を無効にする

Question

「1つの真のルックアップテーブル」という概念は、アンチパターンであり、通常は使用されるべきではありません。しかし、私はPostgresでテーブル継承を使用した場合でもそれが問題ではないかと思いましたか？

マスタールックアップテーブルを読み込んだり挿入したりすることは決してありません。これは他のルックアップテーブルのテンプレートとして多くの機能を果たしますが、参照整合性を失うことはありません（キャッシングブロックで浪費されるスペーステーブルのデータ量が増えるため）、子テーブルを使用して挿入する場合は、型が必要なくなることもあります。そして、あなたはそれのオフ継承

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ですか？

Answer 1

データベース設計に関する多くの大雑把なルールがあります。多くの人々が、ルールの根底にある原則を実際に理解することなく、それらを守る上で "宗教戦争"のポイントに固執しています。本当に素晴らしいスレッドがありますhere男はちょうど質問していますはなぜ悪いですか？そこには "ああ、悪い！"と言っている十数人の人々がいる最終的に少数の現実的なダウンサイドを与える1人の男。

結論として、テーブルが比較的静的な場合、同時に多くのユーザーが同時にデータを入力する必要がない場合、データがテーブルにどのように/どのように/どのように格納されているか、論理設計の観点からは、まだ別々のルックアップ・テーブルをモデル化しているので、おそらくOTLTを物理的な実装として取り除くことができます。

私は25年間データベースを設計してきましたが、私の意見では、その決定の意味が理解できれば、ルールを破ることができます。何かを設計する際には常にトレードオフがあります。あなたの目を開いてトレードオフをしたら、どんな決定になっても良いものになるはずです。

OTLTがホットスポットや迷惑メールにならないように、様々な条件でOKだと仮定すると、提案された物理的な実装は私の見解では「OK」と「エレガント」の間に見えます。