Oui, tout semble correct. Mais...
Quelques remarques :
Nous utiliserions un type de données plus court pour le gender colonne; Je ne vois pas que nous aurions besoin de 255 caractères pour exprimer cela. (Il y a une limite à la taille maximale d'une ligne qui est appliquée.) S'il n'y a que quelques valeurs pour cela, nous considérerons ENUM type de données.
Nous ajouterions aussi probablement NOT NULL contraintes sur plusieurs de ces colonnes, telles que heroname, firstname, lastname. Nous ajouterions aussi probablement DEFAULT '' . Parfois, nous devons vraiment autoriser les valeurs NULL pour une raison quelconque, mais nous utilisons NOT NULL partout où nous pouvons.
J'hésite à propos du TEXT Colonnes. Il n'y a rien de mal à utiliser TEXT type de données, mais je soupçonne simplement que ceux-ci peuvent "cacher" certaines informations qu'il serait préférable de stocker dans des colonnes supplémentaires.
Pour les clés étrangères, nous attribuerions un nom aux contraintes, en suivant le modèle que nous utilisons, et ajouterions probablement ON UPDATE CASCADE ON DELETE CASCADE
CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID)
REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE
Remarque sur les identifiants (noms de table et noms de colonne)
La façon dont nous le faisons, tous les noms de table sont en minuscules . (Nous avons un ensemble d'options MySQL qui force tous les noms de table en minuscules.) Nous faisons cela pour éviter les problèmes d'incompatibilité pour différents systèmes d'exploitation/systèmes de fichiers (dont certains sont sensibles à la casse, et d'autres non).
De plus, les noms de table sont singuliers . Le nom de la table nomme quoi une ligne du tableau représente. Nous n'incluons pas non plus _table dans le cadre du nom.
Les noms de colonne dans MySQL ne sont jamais sensibles à la casse, mais nous utilisons toujours des minuscules pour les noms de colonne également. Nous ne mettons pas en "camelCase" nos noms de colonnes, nous utilisons le caractère de soulignement comme séparateurs, par ex. power_id vs powerID , hero_name vs heroName .
SUIVI
Mes "notes" ci-dessus ne sont pas des règles spécifiques qui doivent être suivies ; ce ne sont que des modèles que nous utilisons.
Suivre ces modèles ne garantit pas que nous aurons un logiciel performant, mais cela nous aide.
Pour votre référence, je vais vous montrer à quoi ressembleraient ces tables comme une "première coupe" de notre boutique, comme illustration d'un autre modèle; ce n'est pas "le bon chemin", c'est juste "un chemin" que nous avons choisi en équipe.
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;
