¿Antipatrón?
En el caso común, la segunda tabla es anti-patrón en el contexto del diseño de bases de datos. Y, más aún, tiene un nombre específico:Entidad-Atributo-Valor (EAV). Hay algunos casos en los que se justifica el uso de este diseño, pero son casos raros, e incluso allí se puede evitar.
Por qué EAV es malo
Soporte de integridad de datos
A pesar de que dicha estructura parece ser más "flexible" o "avanzada", este diseño tiene debilidades.
- Imposible hacer atributos obligatorios . No puede hacer que algún atributo sea obligatorio, ya que el atributo ahora se almacena como una fila, y la única señal de que el atributo no está establecido, es que la fila correspondiente está ausente en la tabla. SQL no le permitirá crear dicha restricción de forma nativa; por lo tanto, tendrá que comprobarlo en la aplicación y, sí, consultar su tabla cada vez
- Combinación de tipos de datos . No podrá utilizar tipos de datos estándar de SQL. Porque su columna de valor debe ser un "supertipo" para todos los valores almacenados en ella. Eso significa que, en general, tendrá que almacenar todos los datos como cadenas sin procesar . Entonces verá lo doloroso que es trabajar con fechas como con cadenas, emitiendo tipos de datos cada vez, comprobando la integridad de los datos, etc.
- Imposible hacer cumplir la integridad referencial . En una situación normal, puede usar una clave externa para restringir sus valores por aquellos que están definidos en la tabla principal. Pero no en este caso, eso se debe a que la integridad referencial se aplica a cada fila de la tabla, pero no a los valores de fila. Entonces, perderá esta ventaja, y es una de las fundamentales en relación DB
- Imposible establecer nombres de atributos . Eso significa que no puede restringir el nombre del atributo en el nivel de base de datos correctamente. Por ejemplo, escribirás
"customer_name"como nombre de atributo en el primer caso, y otro desarrollador lo olvidará y usará"name_of_customer". Y... está bien, DB aprobará eso y terminará con horas dedicadas a depurar este caso.
Reconstrucción de filas
Además, la reconstrucción de filas será terrible en casos comunes. Si tiene, por ejemplo, 5 atributos, serán 5 tablas propias JOIN -s. Lástima para un caso tan simple, a primera vista. Así que no quiero ni imaginar cómo mantendrás 20 atributos.
¿Se puede justificar?
Mi punto es - no. En RDBMS siempre habrá una manera de evitar esto. Es horrible. Y si se pretende usar EAV, entonces la mejor opción puede ser no relacional bases de datos.
