mysql - soporta - Estructura/diseño de la base de datos

modelo de base de datos relacional ejemplo

Question

No podía pensar en un título para esto y, por lo tanto, ni siquiera sabía por dónde empezar a investigar. Tengo que hacer una base de datos donde tengo una tabla para CD / DVD, pero el tipo de entretenimiento en ellos requiere diferentes atributos en términos de metadatos / información, por ejemplo, los CD de música tienen artista, editor, productor, CDNo. etc. Mientras que un software puede tener similitudes, pero tiene algo que la música no tiene y probablemente lo mismo con películas y juegos. Y entonces no estoy seguro de cómo funcionaría esto en términos de un diagrama ER, hasta ahora decidí:

Los CD / DVD que están en la tabla de elementos o en la tabla de existencias aún no están seguros del nombre.

tbl_items -> item_id, item_format (DVD o CD, tal vez axpand to blu-ray o hd-dvd), item_entertainment_type (Música, Película, etc.) <--- Tal vez en otro no estoy seguro. clave externa a una tabla de metadatos, esto es para que cuando se realicen entregas para CD / DVD nuevos si los metadatos ya existan, simplemente ingrese un nuevo elemento y entonces es uno a muchos entre metadatos y elementos (elementos> - meta).

La pregunta que creo es: ¿es una mala práctica tener campos clave externos nulos y simplemente elegir con qué agregar una relación, así que musicMeta_id INT NULL, FOREIGN KEY musicMetaID REFERENCES tbl_musicMeta(musicMeta_id) como esa para cada tipo? o de alguna manera fusionarlos, o hay un truco que tienen las bases de datos.

Estoy usando MySQL con php.

¡Gracias!

Answer 1

Mi opinión: deshacerse de las FOREIGN KEYs ; solo asegúrate de tener los INDEXes adecuados.

Answer 2

No hay una regla general o una mejor práctica para que las claves externas no puedan ser anulables. Muchas veces tiene mucho sentido que una entidad no tenga una relación con otra entidad. Por ejemplo, puede tener una tabla de artistas a los que rastrea pero, por el momento, no tiene CD grabados por esos artistas.

En cuanto a tener Media (CD, DVD, BluRay) que puede ser música / audio o software, puede tener una tabla con la información en común y luego dos claves externas, una para cada tabla de extensión (AudioData y SoftwareData), pero una debe ser NULL Esto presenta una situación llamada, entre otras cosas, un arco exclusivo. Esto generalmente se considera ... problemático.

Piense en una superclase y dos clases derivadas en un lenguaje OO como Java o C ++. Una forma de representar eso en un esquema relacional es:

create table Media(
    ID      int not null, -- identity, auto_generated, generated always as identity...
    Type    char( 1 ) not null,
    Format  char( 1 ) not null,
    ... <other common data>,
    constraint PK_Media primary key( ID ),
    constraint FK_Media_Type foreign key( Type )
        references MediaTypes( ID ), -- A-A/V, S-Software, G-Game
    constraint FK_Media_Format foreign key( Format )
        references MediaFormats( ID ) -- C-CD, D-DVD, B-BluRay, etc.
);
create unique index UQ_Media_ID_Type( ID, Type ) on Media;
create table AVData( -- For music and video
    ID       int not null,
    Type     char( 1 ) not null,
    ... <audio-only data>,
    constraint PK_AVData primary key( ID ),
    constraint CK_AVData_Type check( Type = ''A'',
    constraint FK_AVData_Media foreign key( ID, Type )
        references Media( ID, Type )
);
create table SWData( -- For software, data
    ID       int not null,
    Type     char( 1 ) not null,
    ... <software-only data>,
    constraint PK_SWData primary key( ID ),
    constraint CK_SWData_Type check( Type = ''S'',
    constraint FK_SWData_Media foreign key( ID, Type )
        references Media( ID, Type )
);
create table GameData( -- For games
    ID       int not null,
    Type     char( 1 ) not null,
    ... <game-only data>,
    constraint PK_GameData primary key( ID ),
    constraint CK_GameData_Type check( Type = ''G'',
    constraint FK_GameData_Media foreign key( ID, Type )
        references Media( ID, Type )
);

Ahora, si está buscando una película, busque en la tabla AVData, luego únase a la tabla de medios para el resto de la información, y así sucesivamente con el software o los juegos. Si tiene un valor de ID pero no sabe de qué tipo es, busque en la tabla de Medios y el valor Tipo le dirá a cuál de las tres (o más) tablas de datos se debe unir. El punto es que el FK se refiere a la tabla genérica, no a partir de ella.

Por supuesto, una película o juego o software puede lanzarse en más de un tipo de medio, por lo que puede tener tablas de intersección entre la tabla de Media y las tablas de datos respectivas. Otoh, generalmente están etiquetados con diferentes SKU, por lo que es posible que también desee tratarlos como artículos diferentes.

El código, como era de esperar, puede ser bastante complicado, aunque no demasiado malo. Otoh, nuestro objetivo de diseño no es la simplicidad del código sino la integridad de los datos. Esto hace que sea imposible mezclar, por ejemplo, los datos del juego con un elemento de la película. Y se deshace de tener un conjunto de campos donde solo uno debe tener un valor y los demás deben ser nulos.