propuesta de estructura de tabla mysql?

Question

¿esta tabla es buena para mysql? Quería hacerlo flexible en el futuro para este tipo de almacenamiento de datos. Con esta estructura de la tabla, no se puede utilizar una clave primaria, pero un índice ...

¿Debo cambiar el formato de la tabla para tener cabeceras - Primary Key, anchura, la longitud espacial, Acoplamiento ...

ID_NUM Param Value 
1 Width 5e-081 
1 Length 12 
1 Space 5e-084 
1 Coupling 1.511 
1 Metal Layer  M3-0 
2 Width 5e-082 
2 Length 1.38e-061 
2 Space 5e-081 
2 Coupling 1.5 
2 Metal Layer  M310 

Answer 1

No, este es un mal diseño para una base de datos relacional. Este es un ejemplo del diseño Entity-Attribute-Value. Es flexible, pero rompe la mayoría de las reglas de lo que significa ser una base de datos relacional.

Antes de entrar en el diseño de EAV como una solución para una base de datos flexible, lea esta historia: Bad CaRMa.

Más específicamente, algunos de los problemas con EAV incluyen:

• Usted no sabe qué atributos existen para cualquier ID_NUM dado sin consultar para ellos.
• No puede hacer ningún atributo obligatorio, el equivalente a NOT NULL.
• No puede usar las restricciones de la base de datos.
• No puede usar tipos de datos SQL; la columna value debe ser un VARCHAR largo.
• Particularmente en MySQL, cada VARCHAR se almacena en su propia página de datos, por lo que es un desperdicio.

Las consultas también son increíblemente complejas cuando se utiliza el diseño de EAV. Magento, una plataforma de comercio electrónico de código abierto, usa EAV extensamente, y muchos usuarios dicen que es muy lento y difícil de consultar si necesita informes personalizados.

Para ser relacional, debe almacenar cada atributo diferente en su propia columna, con su propio nombre y un tipo de datos apropiado.

He escrito más sobre EAV en mi presentación Practical Object-Oriented Models in SQL y en mi blog EAV FAIL, y en mi libro, SQL Antipatterns: Avoiding the Pitfalls of Database Programming.

Answer 2

La principal pregunta que debe formularse al crear una tabla especialmente para uso futuro es cómo se recuperarán estos datos y qué propósito tiene. Personalmente, siempre tengo un identificador único, generalmente una identificación para la mesa.

Parece que su lista no tiene nada que defina las entradas de forma única, por lo que no podrá rastrear entradas duplicadas ni recuperar un registro de manera única.

Si desea conservar este diseño, puede crear una clave primaria compuesta compuesta por el nombre y el valor param.

CREATE TABLE testtest (
    ID INT NOT NULL PRIMARY KEY AUTO_INCREMENT, 
    Name VARCHAR(100) NOT NULL, 
    value number NOT NULL 
/*add other fields here*/ 
); 

CREATE TABLE testtest (
    name VARCHAR(100) NOT NULL, 
    value int NOT NULL, 
/*add other fields here*/ 
    primary key(name,value) 
); 

Aquellos crean tabla ejemplo expresar las 2 opciones mencionadas anteriormente.

Answer 3

En mi experiencia, esta idea de almacenar campos por filas necesita ser considerada con extremo cuidado - aunque parece dar muchas ventajas, hace que muchas tareas comunes sean mucho más difíciles.

En el lado positivo: es fácilmente extensible sin cambios en la estructura de la base de datos y de alguna manera abstrae los detalles del almacenamiento de datos.

En el lado negativo: tiene que ver todas las cosas cotidianas almacenando campos en columnas da automáticamente en el DBMS: uniones internas/externas simples, inserciones/actualizaciones de una declaración, unicidad, claves externas y otro nivel de db comprobación de restricciones, simple filtrado de pedidos de anuncios de resultados de búsqueda.

Considere en su arquitectura una consulta para devolver todos los artículos con MetalLayer = X y Ancho entre y y z - resultados ordenados por Acoplamiento por longitud. Esta consulta es mucho más difícil de construir y mucho más difícil de ejecutar para el DBMS de lo que sería usar columnas para almacenar campos específicos.

En la balanza, la única vez que utilicé una estructura como la que sugiere fue en un contexto en el que se debían agregar datos adicionales aleatorios no estructurados de forma ad-hoc. En mi opinión, esta sería una estrategia de último recurso si no hubiera forma de que pudiera hacer funcionar una estructura de tabla más tradicional.

Answer 4

Lo que sugerimos es llamado EAV model (Entity–Attribute–Value)

tiene varias desventajas como graves dificultades para hacer cumplir las restricciones de integridad referencial. Además, las consultas que deberá realizar serán un poco más complicadas que con una tabla normalizada como su segunda sugerencia (tabla con columnas: Primary Key, Width, Length, Space, Coupling, etc).

Entonces, para un proyecto simple, no use el modelo EAV.

Si sus planes son para un proyecto más complejo y desea la máxima flexibilidad, tampoco use EAV. Debería mirar en 6NF (6th Normal Form) que es aún más difícil de implementar y ciertamente no es una tarea fácil en MySQL.Pero si tiene éxito, tendrá ambos bienes: flexibilidad y normalización al más alto nivel (algunas personas llaman "EAV" como "6NF hecho incorrectamente").

Answer 5

Algunas cosas a considerar aquí:

No hay una sola clave principal. Esto puede superarse haciendo que la clave primaria consista en dos columnas (como en el segundo ejemplo de Carl T)

La columna Param se repite y para normalizar esto debe mirar el ejemplo de MGA.

En tercer lugar, la columna "Capa metálica" es una cadena y no un valor flotante como los demás.

Así que es mejor ir a un def tabla como la siguiente:

create table yourTable(
    ID int primary key, 
    ParamId int not null, 
    Width float, 
    Length float, 
    Space float, 
    Coupling float, 
    Metal_layer varchar(20), 
    Foreign key(ParamID) references Param(ID), 
    Value varchar(20) 
) 
create table Param(
    ID int primary key, 
    Name varchar(20) 
)