Estou trabalhando com a nova versão de um aplicativo de terceiros. Nesta versão, a estrutura do banco de dados é alterada, eles dizem "para melhorar o desempenho".

A versão antiga do DB tinha uma estrutura geral como esta:

<code>TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES
(
    ENTITY_ID,
    PROPERTY_KEY,
    PROPERTY_VALUE
)
</code>

Por isso, tínhamos uma tabela principal com campos para as propriedades básicas e uma tabela separada para gerenciar as propriedades personalizadas adicionadas pelo usuário.

A nova versão do DB insted tem uma estrutura como esta:

<code>TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES_n
(
    ENTITY_ID_n,
    CUSTOM_PROPERTY_1,
    CUSTOM_PROPERTY_2,
    CUSTOM_PROPERTY_3,
    ...
)
</code>

Então, agora, quando o usuário adiciona uma propriedade personalizada, uma nova coluna é adicionada à correnteENTITY_PROPERTY mesa até onúmero máximo de colunas (gerenciado pelo aplicativo) é atingido e, em seguida, uma nova tabela é criada.

Então, minha pergunta é: esta é uma maneira correta de projetar uma estrutura de banco de dados? É este o único caminho para"aumentar performances"? A estrutura antiga exigia muitos join ou sub-select, mas essa estrutura não me parece muito inteligente (ou mesmo correta) ...