Sí, todo allí se ve bien. Pero...
Algunas notas:
Usaríamos un tipo de datos más corto para el gender columna; No veo que necesitemos 255 caracteres para expresar eso. (Hay un límite en el tamaño máximo de una fila que se aplica). Si solo hay unos pocos valores para eso, consideraríamos ENUM tipo de datos.
También es probable que agreguemos NOT NULL restricciones en varias de esas columnas, como heroname, firstname, lastname. También es probable que agreguemos DEFAULT '' . A veces, realmente necesitamos permitir valores NULL por alguna razón, pero usamos NOT NULL dondequiera que podamos.
Dudo sobre el TEXT columnas No hay nada de malo en usar TEXT tipo de datos, pero sospecho que esos pueden estar "ocultando" alguna información que podría almacenarse mejor en columnas adicionales.
Para las claves foráneas, asignaríamos un nombre a las restricciones, siguiendo el patrón que usamos, y probablemente también agregaríamos ON UPDATE CASCADE ON DELETE CASCADE
CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID)
REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE
Una nota sobre los identificadores (nombres de tablas y nombres de columnas)
De la forma en que lo hacemos, todos los nombres de las tablas son minúsculas . (Tenemos un conjunto de opciones de MySQL que obliga a que todos los nombres de las tablas estén en minúsculas). Hacemos esto para evitar problemas de incompatibilidad para diferentes sistemas operativos/sistemas de archivos (algunos de los cuales distinguen entre mayúsculas y minúsculas y otros no).
Además, los nombres de las tablas son singular . El nombre de la tabla nombra qué una fila de la tabla representa. Tampoco incluimos _table como parte del nombre.
Los nombres de las columnas en MySQL nunca distinguen entre mayúsculas y minúsculas, pero siempre usamos minúsculas para los nombres de las columnas también. No "camelCase" nuestros nombres de columna, usamos caracteres de subrayado como separadores, p. power_id frente a powerID , hero_name contra heroName .
SEGUIMIENTO
Mis "notas" anteriores no son reglas específicas que deben seguirse; Esos son solo patrones que usamos.
Seguir estos patrones no garantiza que tengamos un software exitoso, pero nos ayuda.
Para su referencia, mostraré cómo se verían estas tablas como un "primer corte" de nuestra tienda, como ilustración de otro patrón; esto es no "la manera correcta", es solo "una manera" que hemos establecido como equipo.
CREATE TABLE superhero
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, hero_name VARCHAR(255) NOT NULL COMMENT ''
, first_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, last_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, first_appearance DATE COMMENT 'date superhero first appeared'
, gender ENUM('female','male','other') COMMENT 'female,male or other'
, biography_text TEXT COMMENT ''
, universe VARCHAR(255) COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY superhero_UX1 (hero_name)
) ENGINE=InnoDB;
CREATE TABLE power
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, name VARCHAR(255) NOT NULL COMMENT ''
, description_text TEXT NOT NULL COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY power_UX1 (name)
) ENGINE=InnoDB;
CREATE TABLE superheropower
( superhero_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref superhero'
, power_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref power'
, PRIMARY KEY(superhero_id, power_id)
, CONSTRAINT FK_superheropower_superhero
FOREIGN KEY(superhero_id) REFERENCES superhero(id)
ON UPDATE CASCADE ON DELETE CASCADE
, CONSTRAINT FK_superheropower_power
FOREIGN KEY (power_id) REFERENCES power(id)
ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;
