From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Lookup tables |
Date: | 2025-02-04 15:19:34 |
Message-ID: | CANzqJaBinU8nF56VcdSx21j1dLKZ+Q0MhUdtujYE+CjkGGMssg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support pgsql-general |
On Tue, Feb 4, 2025 at 10:08 AM Rich Shepard <rshepard(at)appl-ecosys(dot)com>
wrote:
> On Tue, 4 Feb 2025, David G. Johnston wrote:
>
> > The point of a lookup table is to provide a unique list of authoritative
> > values for some purpose. Kinda like an enum. But having the label serve
> as
> > the unique value is reasonable - we only add surrogates for optimization.
>
> David,
>
> The industrytypes table has 26 rows, the statustypes table has 8 rows. Your
> explanation suggests that for this database adding a PK to each table adds
> little, if anything.
>
How big is the database? A tiny 500MB db just for you can get by with poor
design. (But then, why are you using PG instead of SQLite?)
More importantly, will you ever update the descriptions? Of course not!
Famous last words. Having a separate PK means that you update one row in
one column, while what you've done means that tens/hundreds of thousands of
rows in possibly dozens of tables need to be updated.
It also means that *you* can easily change things in your ad hoc
database *without
forgetting* to update a table.
This is called an "update anomaly" in relational design theory.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
From | Date | Subject | |
---|---|---|---|
Next Message | Rich Shepard | 2025-02-04 15:41:48 | Re: Lookup tables |
Previous Message | David G. Johnston | 2025-02-04 15:18:35 | Re: Lookup tables |
From | Date | Subject | |
---|---|---|---|
Next Message | Rich Shepard | 2025-02-04 15:41:48 | Re: Lookup tables |
Previous Message | David G. Johnston | 2025-02-04 15:18:35 | Re: Lookup tables |