É uma boa ideia dividir o campo JSONB em uma tabela separada no meu caso?

No meu caso tenho uma tabela chamada clientes que segue as seguintes informações:

store_listing:
#######
id SERIAL PK
title VARCHAR(100) not null
features JSONB not null
comments TEXT
vat_num VARCHAR(100) NOT null

Essa tabela que uso para gerar:

1. Listagens de clientes (por exemplo, gerações de csv para vários serviços de terceiros)
2. Altere os banners para o site para várias promoções
3. Ative e desative vários recursos aos quais o cliente tem acesso.

Um valor típico pode ser:

{
   banner_cats:{
      active: true,
      types: ['persian','aegean']
   },
   promo_petfest_2023:{
     active: true,
     meta: ['dogs','cats','giraqffes']
   },
   1bank_catzoo: {
     active: true
   },
   feature_virtual_pet: {
     active: true
   }
}

Cada vez que preciso sinalizar e colocar meta em uma Store_listing específica, preciso atualizar a featurescoluna. Também no meu caso, as promoções podem ser geradas em tempo real, por exemplo, uma grande organização (por exemplo, WWE) deseja fazer uma promoção onde colocará banners especiais no meu site. Portanto, terei que atualizar a coluna de integração assim:

{
   banner_cats:{
      active: true,
      types: ['persian','aegean']
   },
   promo_petfest_2023:{
     active: true,
     meta: ['dogs','cats','giraqffes']
   },
   1bank_catzoo: {
     active: true
   },
   feature_virtual_pet: {
     active: true
   },
   wwe_wild_beast_payperview:{
      active: true
   }
}

Isso parece uma má decisão para mim, portanto, pensei nesta abordagem:

features_and_promos_settings
####
listing_id FK store_listing
identifier: String (lowercase, does not contain spaces)
active: boolean
meta: jsonb
type: ENUM(PROMO,FEATURE,BANNER) NULL
#####
PK (listing_id, identifier)

Portanto, no meu caso, a integrationscoluna conterá este valor (listing_id = 1):

{
   banner_cats:{
      active: true,
      types: ['persian','aegean']
   },
   promo_petfest_2023:{
     active: true,
     meta: ['dogs','cats','giraqffes']
   },
   1bank_catzoo: {
     active: true
   },
   feature_virtual_pet: {
     active: true
   },
   wwe_wild_beast_payperview:{
      active: true
   }
}

Vai virar recordes emfeatures_and_promos_settings

Mas essa abordagem me beneficiaria em casos como pesquisa e uso de recursos durante a seleção. O RDMS que usarei é o postgresql-11.

Espero que muitos relatórios sejam gerados para KPIS (por exemplo, para responder a perguntas sobre quantas listagens participaram de uma promoção específica)