anti the anti-pattern (OTLT) in Postgres using Inheritance

I know the concept of "One true lookup table" is an anti-pattern and shouldn't usually be used (ref many many articles on net). However, I wondered if that still the case when you use table inheritance in Postgres?

You would never read or insert into master lookup table - it acts more as a template for your other lookup tables, you don't loose any ref integrity, (possibly you gain space that would otherwise be wasted in your caching blocks due to larger amount of data in tables), and as your inserting through the child tables, you开发者_如何转开发 don't even need a type.

My OTLT would have the following columns that are required for all lookup tables:

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)
)

Then you inherit off of that.

What do people think, is this still a design mistake, is this still OTLT?

There are a lot of rules of thumb around database design and a lot of people get adamant to the point of "religious war" over defending them without really understanding the principles underlying the rule. There's a really awesome thread here where a guy is just asking why is OTLT so evil? There's a dozen people there saying "oh man, it's bad!" and one guy eventually giving a few realistic down-sides.

The bottom line is that if your tables are relatively static, if you don't have too many users hitting them at the same time, if you have controls over who/what/how data gets into the table and if from a logical design perspective you are still modelling separate lookup tables, then you can probably get away with OTLT as a physical implementation.

I've been designing databases for 25 years and in my opinion you should feel free to break a rule as long as you understand what the implications of that decision are going to be. There are always tradeoffs in designing anything. If you make your tradeoffs with your eyes open then whatever decision you come to should be a good one.

Assuming that you're OK on the various provisos like making sure your OTLT won't become a hotspot or a morass for junk then your proposed physical implementation seems somewhere between "OK" and "elegant" in my view.