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 1qnVXs-00B60d-GJ for pgsql-sql@arkaria.postgresql.org; Tue, 03 Oct 2023 02:54:00 +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 1qnVXq-00044K-Js for pgsql-sql@arkaria.postgresql.org; Tue, 03 Oct 2023 02:53:58 +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 1qnVXq-00044C-9l for pgsql-sql@lists.postgresql.org; Tue, 03 Oct 2023 02:53:58 +0000 Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qnVXo-007tk4-13 for pgsql-sql@postgresql.org; Tue, 03 Oct 2023 02:53:57 +0000 Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-6c4e38483d2so272381a34.1 for ; Mon, 02 Oct 2023 19:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696301635; x=1696906435; darn=postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CNNtR11/rTZrv88yQ0a9p19gU9cPOrFg+z1VA8ysMCs=; b=PdbmWjiuwZOchwm1zSmEqdaeaMGFFsbm8Pmc9CCCQ4kgntWf8PZC+6YDJYa/Jo/WPR 0CtLSNR7HsGpPw9b1l/SpVYKhs2ZRSA+3t50uFJzB7urxEJwwItxULuTEirvS+Zb9doL jdZZe/8yz/Fg3nSWe7mGAxdVDbv5cqvyQYVdCIs1q9AQxa2DnKLbDqcZHNxhnwkK6+Ks X3ktHryb6xL39NGMC0/3dvU812kwAFGwBlVg1MzF3KyFVVPVslBH/sRFMRl+KsTZkZvk HR1nAaNejiMdHGm1QkMTEQ8IyoOuLz3funNqUr6RuWu7Ry+u3TnBhxzT3L5W9CxhFros IUDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696301635; x=1696906435; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CNNtR11/rTZrv88yQ0a9p19gU9cPOrFg+z1VA8ysMCs=; b=SLmcxqbZQWcxOaEYHZjFYOqcbHqlRy3RjEicazakpldh4aANxFfpiJs1r0g073Badx dk2Q7EBMpvNau/X48LhND54rHOHpuahosvpQ91h32lStuijbRH15FMswyggxFvZyfQxy dBFpsnaMP+J8LGFrlVFzUhVkWQlJMm4+kd/n2gnj7rwj8YDfIGLjEMVxySqwhauYKExH jyIAutRdoqeo9PhmSJt1BZ6nRdLJvWwS1KJqg8gjkqfWcjPdzibMwVm7xVJI2ot+4R8D Omja5yZ0PPWC+MGMp5NNhqC202Dj9mx+nzbiy3z6zMz44bEJTNdfTdCXFuLml7AFuq9v SkWg== X-Gm-Message-State: AOJu0YyC2uR7HTmDeSMYKcyZFIdwOoLBprSqRdH99PZ6yznWxee6kevb fNHfB7gqDSIRmJQBoeg9thTngiB9RDrskhp4W2R+TNav X-Google-Smtp-Source: AGHT+IEbidCj4QZlXnYJh417ioSlm0LPxCOdhwUMe+7eL/754JEnwdG/JUTP6zpWCHwuTl2AYStQ+gjI8iJVnPHqusQ= X-Received: by 2002:a05:6808:1599:b0:3ae:1b21:fab1 with SMTP id t25-20020a056808159900b003ae1b21fab1mr17891902oiw.31.1696301635010; Mon, 02 Oct 2023 19:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6802:1c87:b0:4f6:384b:17ef with HTTP; Mon, 2 Oct 2023 19:53:54 -0700 (PDT) In-Reply-To: References: From: "David G. Johnston" Date: Mon, 2 Oct 2023 19:53:54 -0700 Message-ID: Subject: Re: A situation with one parent table and 3 child tables To: JORGE MALDONADO Cc: "pgsql-sql@postgresql.org" Content-Type: multipart/alternative; boundary="0000000000006306800606c700e0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006306800606c700e0 Content-Type: text/plain; charset="UTF-8" On Monday, October 2, 2023, JORGE MALDONADO wrote: > Hi, > > I have one parent table (*table_p*) with 3 child tables (*table_ch1*, *table_ch2 > *and *table_ch3*). Each record of the parent table can be associated with > 1 and only 1 child table records. This means that: > > * Some records of the *table_p* will link to records of *table_ch1* > * Some records of the *table_p* will link to records of *table_ch2* > * Some records of the *table_p* will link to records of *table_ch3* > > At first look, this does not make very much sense to me. I thought about > considering 3 parent tables, one for each child table. However, the 3 > parent tables would have the same exact structure and I would like to know > if there is a workaround for this issue. > You are thinking of it backwards. Your chN tables will have FK pointing back to the p table. I suggest adding some kind of type column to the p table indicating which chN table the row belongs to. Then have the same column on the chN table with a check constraint. The key is then the id and that type. You can, with a bit of effort, ensure a row exists on the chN table for every row on the p table but it is circular so must be deferred in enforcement. David J. --0000000000006306800606c700e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, October 2, 2023, JORGE MALDONADO <jorgemal1960@gmail.com> wrote:
Hi,
I have one parent table (table_p) with 3 child tables (= table_ch1, table_ch2 and table_ch3). Each record of th= e parent table can be associated with 1 and only 1 child table records. Thi= s means that:

* Some records of the table_p= will link to records of table_ch1
* Some records of the <= b>table_p will link to records of table_ch2
* Some= records of the table_p will link to records of table_ch3
=

At first look, this does not make very much sense= to me. I thought about considering 3 parent tables, one for each child tab= le. However, the 3 parent tables would have the same exact structure and I = would like to know if there is a workaround=C2=A0for this issue.

You are thinking of it backwa= rds.=C2=A0 Your chN tables will have FK pointing back to the p table.=C2=A0= I suggest adding some kind of type column to the p table indicating which = chN table the row belongs to.=C2=A0 Then have the same column on the chN ta= ble with a check constraint.=C2=A0 The key is then the id and that type.=C2= =A0 You can, with a bit of effort, ensure a row exists on the chN table for= every row on the p table but it is circular so must be deferred in enforce= ment.

David J.

--0000000000006306800606c700e0--