SQL Veel-op-veel-relatie tussen meerdere tabellen

Ja, daar ziet alles er goed uit. Maar...

Een paar opmerkingen:

We zouden een korter gegevenstype gebruiken voor het gender kolom; Ik zie niet in dat we 255 tekens nodig hebben om dat uit te drukken. (Er is een limiet voor de maximale grootte van een rij die wordt afgedwongen.) Als daar maar een paar waarden voor zijn, overwegen we ENUM gegevenstype.

We zouden waarschijnlijk ook NOT NULL . toevoegen beperkingen op verschillende van die kolommen, zoals heldennaam, voornaam, achternaam. We zouden waarschijnlijk ook DEFAULT '' . toevoegen . Soms moeten we om de een of andere reden echt NULL-waarden toestaan, maar we gebruiken NOT NULL waar we maar kunnen.

Ik twijfel over de TEXT kolommen. Er is niets mis met het gebruik van TEXT datatype, maar ik vermoed dat die informatie misschien "verbergen" die beter in extra kolommen kan worden opgeslagen.

Voor de externe sleutels zouden we een naam toewijzen aan de beperkingen, volgens het patroon dat we gebruiken, en waarschijnlijk ook toevoegen ON UPDATE CASCADE ON DELETE CASCADE

CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID) 
  REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE

Een opmerking over identifiers (tabelnamen en kolomnamen)

Zoals we het doen, zijn alle tabelnamen kleine letters . (We hebben een MySQL-optie ingesteld die alle tabelnamen in kleine letters dwingt.) We doen dit om incompatibiliteitsproblemen voor verschillende besturingssystemen/bestandssystemen te voorkomen (waarvan sommige hoofdlettergevoelig zijn en andere niet).

Tabelnamen zijn ook enkelvoud . De naam van de tabel benoemt wat één rij van de tafel vertegenwoordigt. We nemen ook geen _table op als onderdeel van de naam.

Kolomnamen in MySQL zijn nooit hoofdlettergevoelig, maar we gebruiken ook altijd kleine letters voor de kolomnamen. We gebruiken onze kolomnamen niet "camelCase", we gebruiken onderstrepingstekens als scheidingstekens, b.v. power_id vs. powerID , hero_name vs. heroName .

VERVOLG

Mijn "opmerkingen" hierboven zijn geen specifieke regels die moeten worden gevolgd; dat zijn slechts patronen die we gebruiken.

Het volgen van deze patronen is geen garantie dat we een succesvolle software hebben, maar het helpt ons wel.

Ter referentie, ik zal laten zien hoe deze tafels eruit zouden zien als een "eerste snede" uit onze winkel, als illustratie van een ander patroon; dit is niet "de juiste manier", het is gewoon "een manier" die we als team hebben gekozen.

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;