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 1s9ze3-006q1i-DG for pgsql-general@arkaria.postgresql.org; Thu, 23 May 2024 04:01:36 +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 1s9ze2-007W0h-O1 for pgsql-general@arkaria.postgresql.org; Thu, 23 May 2024 04:01:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9ze2-007Vya-Cd for pgsql-general@lists.postgresql.org; Thu, 23 May 2024 04:01:34 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9zdx-000Jig-9L for pgsql-general@lists.postgresql.org; Thu, 23 May 2024 04:01:32 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2e3b1b6e9d1so84569211fa.2 for ; Wed, 22 May 2024 21:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitnine-net.20230601.gappssmtp.com; s=20230601; t=1716436888; x=1717041688; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ofyLOLCt8CNSjP9MLJGl9azsRRRcUqgOMsrFsTCO2To=; b=mM6lfahqoPfMM2hZW+FZfYN4HufsWponIZMWl0DY+qN/j/gBMwZnEs2n/NaB9LorWz wBb3E3LwGZlwSU6UsegJ8ZXoE78+FZcYRBjxebTkX+tbjr+Go2Qh7lUoMf4OtuaMrD80 PkqPvIk15YgU2NrPPrrC6KPLB+431olGoB6otpz6Sk3dEkh5OhjRZrdaGPCp+iN7+diY h/yhs2BWhD9k3mUqexgYVJVaJ0lVRiqm9UXhXbL2uSr/J2OVD4HBIl2unvxvfzSco+25 PEsCn7PLX0/gzw+yNsgPDaxUsBpYLEd4k5a2mAIHYPpA5v5sdMQuZTz8YEC4adHjm0X8 llEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716436888; x=1717041688; h=cc: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=ofyLOLCt8CNSjP9MLJGl9azsRRRcUqgOMsrFsTCO2To=; b=R1ESDK5gVIqrscgZkaVGAPtNKZLmFdoVc9qpT7OTMb1vzVJN8yHQdB7MYHklsZM6bh FzLKBG1u6zGcEDjD0HXDVQ87d6YLFlrboTEuLRAX1Vp3mfY5sJh+ThP5rL1RNciuC1sB MQsKTJAqMVkGY8FbAeGFJl0ndT64dU1qYKkXTFewnM/hrx1gZlNEMsaexUFw5tF6vub2 KCRHDcNfUdWti11vpbrlCkiOlYcgLSXQq6/IvJSMB3+Gjz+0KLaFxRxvlkSFz89ZzI0N G6iLXmaoXiW9uONycujk0RIitE5bM/whR9DMe5pW1/Q17P4+G9UUU10cqNSIvddV5Qjc Nxzg== X-Gm-Message-State: AOJu0Yz3LXSytHBydXcg70qHk7zm1g8VZ3jSUSb3Nl+Mvr41Ax6frAfF DPucDXLfNyrh1DSLIgyVpPFcgn1N8XlWdG1lr/NH7vHJI2f55hFacjSrdhK+QEkvY1i1Ix1wWmN ooqUpNjuvRF4q2qEWmoqfOV4fedqtjFrNLRPrwg== X-Google-Smtp-Source: AGHT+IHtp3OxoGidQTiLqpol1GXZjLX8unIja0ut1O2IPGutsZ3RlALo2KL7ArL+x9BfB+S+6+QPXlHNtRzUszOFA7M= X-Received: by 2002:a2e:95d4:0:b0:2e1:d44b:db9c with SMTP id 38308e7fff4ca-2e9492c7dd5mr21062081fa.0.1716436888046; Wed, 22 May 2024 21:01:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Salahuddin Manzoor Date: Thu, 23 May 2024 09:01:16 +0500 Message-ID: Subject: Re: Json table/column design question To: Skorpeo Skorpeo Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000fde4270619171a7a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fde4270619171a7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings, Storing unrelated JSON objects in the same table with distinct columns for each type (e.g., "Users" and "Inventory") is generally not a sound good approach may affect Query Performance and Optimization, Storage Efficiency, scalability and Maintenance, Data Integrity. Recommended approach is to have separate tables. *Salahuddin (=EC=82=B4=EB=9D=BC=ED=9B=84=EB=94=98* *)* On Thu, 23 May 2024 at 08:39, Skorpeo Skorpeo wrote: > Hi, > > I was wondering if having unrelated columns in a table is a sound approac= h > when using json. In other words, if I have two collections of unrelated > json objects, for example "Users" and "Inventory", would it be ok to have > one table with a "Users" column and a "Inventory" column? My concern is > that from a row perspective the columns could be different lengths, such = as > more inventory items as users. And for any given row the data in one > column would have no relation to another column. I would only query a > single column at a time. > > Would this approach be ok or are there pitfalls such that it would be > advantageous/recommended to have a separate table for each column? > > Any thoughts/inputs are greatly appreciated. > > Many thanks. > --000000000000fde4270619171a7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,
Storing unrelated JSON objects in the same = table with distinct columns for each type (e.g., "Users" and &quo= t;Inventory") is generally not a sound good approach may affect Query = Performance and Optimization, Storage Efficiency, scalability and Maintenan= ce, Data Integrity.
Recommended approach is to have separate tables.
<= /tbody>

Salahuddin (= =EC=82=B4=EB=9D=BC=ED=9B=84=EB=94=98)



On Thu, 23 May 2024 at 08:39, Sk= orpeo Skorpeo <skorpeo11@gmail.co= m> wrote:
Hi,

I was wondering if havi= ng unrelated columns in a table is a sound approach when using json.=C2=A0 = In other words, if I have two collections of unrelated json objects, for ex= ample "Users" and "Inventory", would it be ok to have o= ne table with a "Users" column and a "Inventory" column= ?=C2=A0 My concern is that from a row perspective the columns could be diff= erent lengths, such as more inventory items as users.=C2=A0 And for any giv= en row the data in one column would have no relation to another column. I w= ould only query a single column at a time.

Would t= his approach be ok or are there pitfalls such that it would be advantageous= /recommended to have a separate table for each column?

=
Any thoughts/inputs are greatly appreciated.

= Many thanks.
--000000000000fde4270619171a7a--