Date: Thu, 15 Apr 2021 15:15:23 +0200
From: Bzzzz <lazyvirus@gmx.com>
To: pgsql-novice@lists.postgresql.org
Cc: steve@tusol.co.uk
Subject: Re: Advice on foreign key and cascading delete design - postgresql
 12.6
Message-ID: <20210415151523.3a59e334@msi.defcon1.lan>
In-Reply-To: <b047654785ee3f4f8ea1e6e948bfa22563baeed1.camel@tusol.co.uk>
References: <c1cfdf4054e8480d28fbf7fb2e15912d3996ee69.camel@tusol.co.uk>
	<3190280.1618325238@sss.pgh.pa.us>
	<be3406b4935379ea0523365d9954b91ee349b93f.camel@tusol.co.uk>
	<20210413180841.3ba6e741@msi.defcon1.lan>
	<f0e99cfb734baba7a7f41397f27e222cfe385ee8.camel@tusol.co.uk>
	<20210414142719.181ffd62@msi.defcon1.lan>
	<b047654785ee3f4f8ea1e6e948bfa22563baeed1.camel@tusol.co.uk>
Organization: Anyone, anywhere but in banana demokratik republik of france
 or UERSS.
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/20210415151523.3a59e334%40msi.defcon1.lan>
Precedence: bulk

On Thu, 15 Apr 2021 08:07:20 +0100
"Steve Tucknott (TuSol)" <steve@tusol.co.uk> wrote:

[2nd sent, the first one wasn't on the ML]

> Thanks Jean-Yves, that makes more sense - although I do find
> 'normalised' structures slightly frustrating even though I can see that
> the structure works.
> You say that it's bad design having the foreigntablename on the
> dependency as it's not practical if the number of dependent tables is
> large, =20

> but why is it any better then having many 'intermediate
> main-to- dependency' tables? =20

Because of=E2=80=A6 normalized structure ;-p)
Using it, there is no repetition of any kind.

> I think I've gone full circle in that I currently control the orphans
> via hand cranked code - but I hadn't functionalised it. It seems that
> another option is to make the tidy up generic by using the information
> schemas in a function that  purges all records that carry a
> 'foreigntablename' and 'foreignrecno' for the main table. =20

You just read old_table and write new_table with the columns you need
(transforming 'foreigntablename' and 'foreignrecno' references into
foreign keys references in this process), write the wanted functions and
triggers, test them thoroughly in a test DB, triple-check everything's
ok, delete the original table and finally, rename the new_table to the
old name and re-check the whole shebang.

Or you can make a text dump of old_table, modify it with sed and go on
with the rest of the process.

I would do all of this in a test DB then, when everything is checked,
make a dump of it, manually edit this dump to only keep what is needed
and apply it to the regular DB.
This would avoid downtime and make (almost) inevitable blunders
acceptable.

HINT: write down the whole procedure sequentially on a large sheet of
      paper with notes where needed, also write down your functions and
      triggers, write down the test procedures, triple-check everything's
      consistent and proceed step by step with no stress.

> Thanks again for the time and effort you've put into explaining this
> for me. =20

You're welcome.

Jean-Yves