On Monday, October 2, 2023, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, October 2, 2023, JORGE MALDONADO <jorgemal1960@gmail.com> wrote:
>> 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.
Do you need that? I was wondering about converting the 3 child tables
into a partitioned table. Then you can query them separately when
you need to, but you can also treat them as one table --- and you
can set up one FK constraint between that and the parent table.
This sounds like a typical subclassing (animal -> {dog,cat,moose}) structure where I am assuming the children have different subtype-specific columns.
David J.