Re: Need help in database design

Also as you ask how 50 pairs turns into 50 column so each column will be a
key and the value of that key will store inside their respective column for
each row

On Mon, 23 Dec 2024, 10:14 pm Divyansh Gupta JNsThMAudy, <
ag1567827(at)gmail(dot)com> wrote:

> As per the discussion with other team members they suggested if we store
> 50 values for keys in an individual column that will provide better
> performance as the data type is native (INT2) on the other hand if we store
> all the key value pair in a single JSONB column the performance will
> degrade even after applying a GIN index on that however the statement
> sounds funny but I want to take everyone openion?
>
> On Mon, 23 Dec 2024, 10:05 pm Adrian Klaver, <adrian(dot)klaver(at)aklaver(dot)com>
> wrote:
>
>> On 12/23/24 07:53, Divyansh Gupta JNsThMAudy wrote:
>> > Hii Community,
>> >
>> > I need to provide a support for some functionality for my application
>> > for that I need to store 50 key value pair set, so I am in a dilemma,
>> > weather I create 50 new columns of int2 data type each column will
>>
>> This is unclear, I am trying to figure out you go from '50 key value
>> pair set' to '50 new columns of int2'.
>>
>> In other words how 50 pairs turn into 50 columns?
>>
>> Then there is the question of why 50 keys per row in the first place?
>>
>>
>> > contain value of a specific key or should I go with JSONB data type
>> with
>> > 50 key value pair, the table on which I am going to do that all
>> contains
>> > 1 Billion rows of data and have 84 hash partitions, I have gone through
>> > multiple articles some of them mentioned it's a good approach to create
>> > 50 new columns and some states that creating one JSONB would be best
>> > that's why I need your help to move forward, also I am ready to make
>> > H-Store instead of JSONB if it provides better performance.
>> > Please help me to comes out from that dilemma.
>> >
>> > Regards,
>> > Divyansh Gupta,
>> > Database Administrator
>>
>> --
>> Adrian Klaver
>> adrian(dot)klaver(at)aklaver(dot)com
>>
>>