Estoy trabajando con la nueva versión de una aplicación de terceros. En esta versión, la estructura de la base de datos cambia, dicen "para mejorar el rendimiento".¿Es este un diseño de base de datos "correcto"?
La versión anterior de la base de datos tenía una estructura general de esta manera:
TABLE ENTITY
(
ENTITY_ID,
STANDARD_PROPERTY_1,
STANDARD_PROPERTY_2,
STANDARD_PROPERTY_3,
...
)
TABLE ENTITY_PROPERTIES
(
ENTITY_ID,
PROPERTY_KEY,
PROPERTY_VALUE
)
así que tuvimos una mesa principal con los campos para las propiedades básicas y una tabla separada para administrar las propiedades personalizadas añadidas por el usuario.
La nueva versión de la base de datos insted tiene una estructura como esta:
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,
...
)
lo tanto, ahora cuando el usuario añada una propiedad personalizada, se añade una nueva columna a la
ENTITY_PROPERTY
tabla actual hasta que el número
máximo
de las 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 forma de "aumentar el rendimiento"? La antigua estructura requería muchos join o sub-select, pero esta estructura no me parece muy inteligente (o incluso correcta) ...
"aguarde el día en que se encuentre con el número máximo de tablas por base de datos" ... pero puede crear una nueva base de datos ;-) +1 para ver la arquitectura general y desearía dar otro +1 por costo en cascada de la reingeniería DAL, pruebas unitarias, ... –