Subject: One parent record with 3 possible child records

From: JORGE MALDONADO <[email-masked]>
Date: Wed, 1 May 2024 18:08:33 -0500

Hi,

I have one table that can have relations to only 1 of 3 possible tables.
For example: tblMain*,* tblOne, tblTwo and tblThree.

I will always have 1 record in tblMain but each record in this table will
be related to one record in tblOne OR one record in tblTwo OR one record in
tblThree.

The relation between tblMain and tblOne is 1:1.
The relation between tblMain and tblTwo is 1:1.
The relation between tblMain and tblThree is 1:1.

Is it better to set tblMain as parent or child?

This can be seen as if tblOne, tblTwo and tblThree
extend tblMain depending on a specific criteria.

Let's say that tableMain has a string field called "type" with the
following possible values: "residential", "industrial" and "energy".

I will always insert a record in tblMain but:
* If type is "residential" then a record in tblOne is created and it is
associated to tblMain,
* If type is "industrial" a record in tblTwo is created and it is
associated to tblMain
* If type is "energy" a record in tblThree is created and it is associated
to tblMain.

I am not sure how to design a case like this. I will very much appreciate
your feedback.

Best regards,
Jorge Maldonado

---

From: "David G. Johnston" <[email-masked]>
Date: Wed, 1 May 2024 16:24:15 -0700

> following possible values: "residential", "industrial" and "energy".

This, and have the same column in the other tables, but add a check
constraint ensuring only the correct enum value can be specified.  Then
your foreign key from the child tables to main is both the ID and the type
field.

David J.

---

From: Sanjay Minni <[email-masked]>
Date: Thu, 2 May 2024 19:03:44 +0530

maybe unorthodox but if its certain to be 1:1 then why not flatten it to a
single table with all the possible columns
(tblMain+tblOne+tblTwo+tblThree). You can keep a flag to indicate the type.
there may be a gain in simplicity without losing anything.

Sanjay

---

From: Rob Sargent <[email-masked]>
Date: Thu, 2 May 2024 07:37:14 -0600

> On May 1, 2024, at 5:24 PM, David G. Johnston <[email-masked]> wrote:
> 
> On Wednesday, May 1, 2024, JORGE MALDONADO <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Let's say that tableMain has a string field called "type" with the following possible values: "residential", "industrial" and "energy". 
> 
> This, and have the same column in the other tables, but add a check constraint ensuring only the correct enum value can be specified.  Then your foreign key from the child tables to main is both the ID and the type field.
>  
> David J.
Presuming the id is unique in parent and child, what’s the value of the type field in the foreign key?  Are you saying the PK on tableMain is (type,id), perhaps for clustering purposes?

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 2 May 2024 07:02:37 -0700

On Thu, May 2, 2024 at 6:37 AM Rob Sargent <[email-masked]> wrote:

> Presuming the id is unique in parent and child, what’s the value of the
> type field in the foreign key?  Are you saying the PK on tableMain is
> (type,id), perhaps for clustering purposes?
>
>
>
Preventing the parent record from saying "tblOne" while the actual ID value
is present on "tblTwo".

David J.

---

From: "Wetmore, Matthew (CTR)" <[email-masked]>
Date: Thu, 2 May 2024 14:37:09 +0000

Wouldn’t page size performance be decreased with a very wide table?  Unless the columns are tight.  If you are on a VM subsystem, that page bloat will be over the network from the memory controller.

From: Sanjay Minni <[email-masked]>
Sent: Thursday, May 2, 2024 6:34 AM
To: JORGE MALDONADO <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: One parent record with 3 possible child records

maybe unorthodox but if its certain to be 1:1 then why not flatten it to a single table with all the possible columns (tblMain+tblOne+tblTwo+tblThree). You can keep a flag to indicate the type. there may be a gain in simplicity without losing anything.

Sanjay

On Thu, May 2, 2024 at 4:39 AM JORGE MALDONADO <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I have one table that can have relations to only 1 of 3 possible tables. For example: tblMain, tblOne, tblTwo and tblThree.

I will always have 1 record in tblMain but each record in this table will be related to one record in tblOne OR one record in tblTwo OR one record in tblThree.

This can be seen as if tblOne, tblTwo and tblThree extend tblMain depending on a specific criteria.

I will always insert a record in tblMain but:
* If type is "residential" then a record in tblOne is created and it is associated to tblMain,
* If type is "industrial" a record in tblTwo is created and it is associated to tblMain
* If type is "energy" a record in tblThree is created and it is associated to tblMain.

I am not sure how to design a case like this. I will very much appreciate your feedback.

Best regards,
Jorge Maldonado

---

From: Sanjay Minni <[email-masked]>
Date: Thu, 2 May 2024 20:42:42 +0530

As I understand postgres does not reserve or use space for columns having
no content. If that's so then the bloat will be insignificant . But off
course the pros and cons of embedding the columns inline have to be weighed

On Thu, 2 May, 2024, 8:07 pm Wetmore, Matthew (CTR), <
[email-masked]> wrote:

> Wouldn’t page size performance be decreased with a very wide table?
> Unless the columns are tight.  If you are on a VM subsystem, that page
> bloat will be over the network from the memory controller.
>
>
>
> *From:* Sanjay Minni <[email-masked]>
> *Sent:* Thursday, May 2, 2024 6:34 AM
> *To:* JORGE MALDONADO <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [EXTERNAL] Re: One parent record with 3 possible child records
>
>
>

---

From: Rob Sargent <[email-masked]>
Date: Thu, 2 May 2024 12:28:42 -0600

Gotcha, thanks

On May 2, 2024, at 8:03 AM, David G. Johnston <[email-masked]> wrote:

Preventing the parent record from saying "tblOne" while the actual ID value is present on "tblTwo".

David J.

---

From: Nic Mitchell <[email-masked]>
Date: Thu, 2 May 2024 23:47:46 +0100

On 02/05/2024 00:08, JORGE MALDONADO wrote:
> I will always have 1 record in tblMain but each record in this table 
> will be related to one record in tblOne OR one record in tblTwo OR one 
> record in tblThree.
> 

I worked with a similar looking, I think, relationship for a time. The 
idea was that, using trigger functions, rows in the _object table - your 
tblMain - would be inserted/deleted only ever as a result of 
inserting/deleting rows in the tables _objecttype[1-3] - your tblOne, 
tblTwo and tblThree.

I came up with this attempting to solve a problem where I needed to be 
able to model groups that could contain objects of different types, each 
of which had to be stored in their own table.

So, here's the code...

CREATE TABLE public._objecttype (
	_id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( START WITH 10001 ),
	_name text NOT NULL,
	CONSTRAINT _objecttype_pkey PRIMARY KEY (_id),
	CONSTRAINT _objecttype__name_key UNIQUE (_name)
);

COMMENT ON TABLE public._objecttype IS E'values in _name column will be 
_objectype1,  _objectype2, and _objectype3';

CREATE TABLE public._object (
	_id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( START WITH 20001 ),
	_objecttype_id integer NOT NULL,
	CONSTRAINT _object_pkey PRIMARY KEY (_id)
);

CREATE TABLE public._objecttype1 (
	_object_id integer NOT NULL,
	_name text NOT NULL,
	CONSTRAINT _objecttype1_pkey PRIMARY KEY (_object_id),
	CONSTRAINT _objecttype1__name_key UNIQUE (_name)
);

CREATE TABLE public._objecttype2 (
	_object_id integer NOT NULL,
	_name text NOT NULL,
	CONSTRAINT _objecttype2_pkey PRIMARY KEY (_object_id),
	CONSTRAINT _objecttype2__name_key UNIQUE (_name)
);

CREATE TABLE public._objecttype3 (
	_object_id integer NOT NULL,
	_name text NOT NULL,
	CONSTRAINT _objecttype3_pkey PRIMARY KEY (_object_id),
	CONSTRAINT _objecttype3__name_key UNIQUE (_name)
);

CREATE FUNCTION public._tf_biu_createobject ()
	RETURNS trigger
	LANGUAGE plpgsql
	AS $$
begin
if NEW._object_id is NULL then
	WITH object_id AS (
     INSERT INTO _object (_objecttype_id)
     VALUES (
		(
		SELECT _objecttype._id
		FROM _objecttype
		WHERE _objecttype._name
		LIKE TG_TABLE_NAME
		)
	)
     RETURNING _id)
     SELECT * FROM object_id INTO NEW._object_id;
end if;
return NEW;
end;
$$;

CREATE TRIGGER _t_biu_createobject
	BEFORE INSERT OR UPDATE
	ON public._objecttype1
	FOR EACH ROW
	EXECUTE PROCEDURE public._tf_biu_createobject();

CREATE TRIGGER _t_biu_createobject
	BEFORE INSERT OR UPDATE
	ON public._objecttype2
	FOR EACH ROW
	EXECUTE PROCEDURE public._tf_biu_createobject();

CREATE TRIGGER _t_biu_createobject
	BEFORE INSERT OR UPDATE
	ON public._objecttype3
	FOR EACH ROW
	EXECUTE PROCEDURE public._tf_biu_createobject();

CREATE FUNCTION public._tf_ad_deleteobject ()
	RETURNS trigger
	LANGUAGE plpgsql
	AS $$
begin
   DELETE FROM _object
   WHERE _object._id = OLD._object_id;
   return NULL;
end
$$;

CREATE TRIGGER _t_ad_deleteobject
	AFTER DELETE
	ON public._objecttype1
	FOR EACH ROW
	EXECUTE PROCEDURE public._tf_ad_deleteobject();

CREATE TRIGGER _t_ad_deleteobject
	AFTER DELETE
	ON public._objecttype2
	FOR EACH ROW
	EXECUTE PROCEDURE public._tf_ad_deleteobject();

CREATE TRIGGER _t_ad_deleteobject
	AFTER DELETE
	ON public._objecttype3
	FOR EACH ROW
	EXECUTE PROCEDURE public._tf_ad_deleteobject();

ALTER TABLE public._object ADD CONSTRAINT _object__objecttype_id_fkey 
FOREIGN KEY (_objecttype_id)
REFERENCES public._objecttype (_id) MATCH SIMPLE
ON DELETE RESTRICT ON UPDATE NO ACTION;

ALTER TABLE public._objecttype1 ADD CONSTRAINT 
_objecttype1__object_id_fkey FOREIGN KEY (_object_id)
REFERENCES public._object (_id) MATCH SIMPLE
ON DELETE RESTRICT ON UPDATE NO ACTION;

ALTER TABLE public._objecttype2 ADD CONSTRAINT 
_objecttype2__object_id_fkey FOREIGN KEY (_object_id)
REFERENCES public._object (_id) MATCH SIMPLE
ON DELETE RESTRICT ON UPDATE NO ACTION;

ALTER TABLE public._objecttype3 ADD CONSTRAINT 
_objecttype3__object_id_fkey FOREIGN KEY (_object_id)
REFERENCES public._object (_id) MATCH SIMPLE
ON DELETE RESTRICT ON UPDATE NO ACTION;