Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfKiM-001Upi-Mu for pgsql-general@arkaria.postgresql.org; Tue, 04 Feb 2025 15:19:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tfKiL-004dvx-Rh for pgsql-general@arkaria.postgresql.org; Tue, 04 Feb 2025 15:19:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfKiL-004dvp-Go for pgsql-general@lists.postgresql.org; Tue, 04 Feb 2025 15:19:49 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tfKiJ-0038mC-01 for pgsql-general@postgresql.org; Tue, 04 Feb 2025 15:19:48 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-2a3c075ddb6so2979616fac.2 for ; Tue, 04 Feb 2025 07:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738682387; x=1739287187; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=WEluKQ4EBjaMHgVN8Yxn5VtGYQSj5UnryqiY6AuGQws=; b=KOYLeeHHujc/W16DLX7LbIf6F16TGrzcbqRvYNvDS393zRmQc31vou0hKufDD+gw/j hdu7jE9MFqKB2rL2CKGo52XQGtnO9cthbjfj82CbBZlTXzczXEuxsIGOom/VaVGvYlBF 5ksHnqk7Z+NEqwNrC72XUQY5EAOndUKclr+QGeG5zNx7/239emvqafEf8DCcxeQdTz5D NlHl+2VbHV4SyDFuL3jqQ1MIGGJGnMANhs7WfUqoyhmvaQGcZyzO25v5xuC1EMIqDxxj hpVmK8GZifMO+CrrForRverh0pxxp3AEc/C6n+kjrUg0Dj7iuiMRNN70IoDDS2kHpcpe EP/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738682387; x=1739287187; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WEluKQ4EBjaMHgVN8Yxn5VtGYQSj5UnryqiY6AuGQws=; b=HtGy8hX66u+1FESc4EHCc4+ieVEcnzXAKe5p0SgGCFDKBjUZEKAIyt8j3u8Sbz64XG RPW26GaZ/pdsp/hkFJCh/2+gw6fgXFSL9r6jUBbXzAB7WOFdDsCO4/1FrPmmH78VtNuj eEOLYKll/UStBuQxhJzR5SXJADM9yTEA9UECdxBHsVjRGOoYBaGH0IqcR2YRQ0bEtCD5 I3DHWmA2FOFnVX/1neFrwTxX0r2iyPA/cZKmilNKUsH6xgOe/ONZnGlaDotVOhJYnIxU ztPR/FJ9ZQbObFpintxqCuRhcKhE4uqk28ZukFjQkdeLsNmd6LfPoYCOuL5tFvH2rpr/ aRyQ== X-Gm-Message-State: AOJu0YygeAry2FWD5DGaDVBBRn2uzXy3CCPJ2p/XVeE8kypNrFZrBfBn DioORQkjPn6r2j4NhBN/pzmb6x11BxniDYt938/ALLITmc8oArlfRvDPv4uFPDqjOFi9HpqfR5D w/ICEBa3K6bZabxBjdduwJpU9Z6rFKA== X-Gm-Gg: ASbGncutNLuGfDd55Ly2+lzxKvCpC80mL1GEZUOzjB0Y4psuNfrqFu3eO9qj5SpRb77 N1rlS/Yp3LGK2kwhFQNFzdLs0g/de92effrYlWsBi/w6fdyvRjQT4OViEDQdRWcMzeDspSPC9wG gZPB8o5ds1TMY2N3j5yBtxeWItv/fnVbg= X-Google-Smtp-Source: AGHT+IHzmKh7Sr8FIbqcsMoRO4UfBZC6EIjlIIfZSSB/OcnfGJ8Ooql6tSCiV3rhzTJvCisfPwR3fmqSdsYCY0oDmEo= X-Received: by 2002:a05:6870:a2c5:b0:2b3:55b3:e38 with SMTP id 586e51a60fabf-2b355b32e89mr9802205fac.21.1738682385235; Tue, 04 Feb 2025 07:19:45 -0800 (PST) MIME-Version: 1.0 References: <4e7a338-c7d3-e944-20bd-a6e346e175c7@appl-ecosys.com> In-Reply-To: From: Ron Johnson Date: Tue, 4 Feb 2025 10:19:34 -0500 X-Gm-Features: AWEUYZn12QtnGhIdZ7Ft3OmWTI-lKQVOWfx9aCtPf3AzMrGY5HJq1FqdDly0KCc Message-ID: Subject: Re: Lookup tables To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000f30690062d52891e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f30690062d52891e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2025 at 10:08=E2=80=AFAM Rich Shepard wrote: > On Tue, 4 Feb 2025, David G. Johnston wrote: > > > The point of a lookup table is to provide a unique list of authoritativ= e > > values for some purpose. Kinda like an enum. But having the label serve > as > > the unique value is reasonable - we only add surrogates for optimizatio= n. > > David, > > The industrytypes table has 26 rows, the statustypes table has 8 rows. Yo= ur > explanation suggests that for this database adding a PK to each table add= s > 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. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000f30690062d52891e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2025 at 10:08=E2=80=AFAM R= ich Shepard <rshepard@appl-e= cosys.com> wrote:
On Tue, 4 Feb 2025, D= avid G. Johnston wrote:

> The point of a lookup table is to provide a unique list of authoritati= ve
> values for some purpose. Kinda like an enum. But having the label serv= e as
> the unique value is reasonable - we only add surrogates for optimizati= on.

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<= br> little, if anything.

How big is the dat= abase?=C2=A0 A tiny 500MB db just for you can get by with poor design.=C2= =A0 (But then, why are you using PG instead of SQLite?)

More importantly, will you ever update the descriptions?=C2=A0 Of=C2= =A0course not! Famous last words.=C2=A0 Having a separate=C2=A0PK means tha= t you update one row in one column, while what you've done means that t= ens/hundreds of thousands of rows in possibly dozens of tables need to be u= pdated.

It also means that you=C2=A0can eas= ily change things in your ad hoc database without forgetting to upda= te 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> lobs= ter!
--000000000000f30690062d52891e--