SQL mange-til-mange-forhold mellem flere tabeller

Ja, alt ser okay ud. Men...

Et par bemærkninger:

Vi ville bruge en kortere datatype for gender kolonne; Jeg kan ikke se, at vi skal bruge 255 tegn for at udtrykke det. (Der er en grænse for den maksimale størrelse af en række, som håndhæves.) Hvis der kun er nogle få værdier for det, vil vi overveje ENUM datatype.

Vi vil sandsynligvis også tilføje NOT NULL begrænsninger på flere af disse kolonner, såsom heltenavn, fornavn, efternavn. Vi vil sandsynligvis også tilføje DEFAULT '' . Nogle gange er vi virkelig nødt til at tillade NULL-værdier af en eller anden grund, men vi bruger NOT NULL hvor vi kan.

Jeg tøver med TEXT kolonner. Der er ikke noget galt med at bruge TEXT datatype, men jeg er bare i tvivl om, at de måske "skjuler" nogle oplysninger, som måske bedre kan gemmes i yderligere kolonner.

For fremmednøglerne vil vi tildele et navn til begrænsningerne, efter det mønster, vi bruger, og sandsynligvis tilføje ON UPDATE CASCADE ON DELETE CASCADE

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

En note om identifikatorer (tabelnavne og kolonnenavne)

Som vi gør det, er alle tabelnavne små bogstaver . (Vi har et MySQL-indstillingssæt, der tvinger alle tabelnavne til små bogstaver.) Vi gør dette for at undgå inkompatibilitetsproblemer for forskellige operativsystemer/filsystemer (hvoraf nogle er store og små bogstaver, og nogle ikke).

Tabelnavne er også ental . Navnet på tabellen navngiver hvad en række af tabellen repræsenterer. Vi inkluderer heller ikke _table som en del af navnet.

Kolonnenavne i MySQL skelner aldrig mellem store og små bogstaver, men vi bruger også altid små bogstaver til kolonnenavnene. Vi "camelCase" ikke vores kolonnenavne, vi bruger understregningstegn som skilletegn, f.eks. power_id vs. powerID , hero_name vs. heroName .

OPFØLGNING

Mine "noter" ovenfor er ikke specifikke regler, der skal følges; det er bare mønstre, vi bruger.

At følge disse mønstre garanterer ikke, at vi får en succesfuld software, men det hjælper os.

Til din reference vil jeg vise, hvordan disse borde ville se ud som et "første snit" fra vores butik, som en illustration af et andet mønster; dette er ikke "den rigtige måde", det er bare "en måde", som vi har lagt os fast på som et hold.

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;