Estoy trabajando con la nueva versión de una aplicación de terceros. En esta versión, se cambia la estructura de la base de datos, dicen "para mejorar el rendimiento".

La versión anterior del DB tenía una estructura general 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>

así que teníamos una tabla principal con campos para las propiedades básicas y una tabla separada para administrar las propiedades personalizadas agregadas por el usuario.

La nueva versión del DB insted tiene una estructura 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>

Entonces, ahora que el usuario agrega una propiedad personalizada, se agrega una nueva columna a la actualENTITY_PROPERTY mesa hasta lanúmero máximo de columnas (administrado por la aplicación) se alcanza, luego se crea una nueva tabla.

Entonces, mi pregunta es: ¿Es esta una forma correcta de diseñar una estructura de base de datos? ¿Es esta la única manera de"aumentar el rendimiento"? La estructura anterior requería muchas combinaciones o subselecciones, pero esta estructura no me parece muy inteligente (ni siquiera correcta) ...