SQL många-till-många-relation mellan flera tabeller

Ja, allt ser bra ut där. Men...

Några anteckningar:

Vi skulle använda en kortare datatyp för gender kolumn; Jag ser inte att vi skulle behöva 255 tecken för att uttrycka det. (Det finns en gräns för den maximala storleken på en rad som tillämpas.) Om det bara finns ett fåtal värden för det, skulle vi överväga ENUM datatyp.

Vi skulle sannolikt också lägga till NOT NULL begränsningar för flera av dessa kolumner, som hjältenamn, förnamn, efternamn. Vi skulle sannolikt också lägga till DEFAULT '' . Ibland behöver vi verkligen tillåta NULL-värden av någon anledning, men vi använder NOT NULL var vi än kan.

Jag är tveksam till TEXT kolumner. Det är inget fel med att använda TEXT datatyp, men jag är bara misstänksam om att de kan "gömma" viss information som kanske bättre kan lagras i ytterligare kolumner.

För de främmande nycklarna skulle vi tilldela begränsningarna ett namn, enligt mönstret vi använder, och sannolikt även lägga till ON UPDATE CASCADE ON DELETE CASCADE

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

En notering om identifierare (tabellnamn och kolumnnamn)

Som vi gör det är alla tabellnamn gemener . (Vi har en MySQL-alternativuppsättning som tvingar alla tabellnamn till gemener.) Vi gör detta för att undvika inkompatibilitetsproblem för olika operativsystem/filsystem (varav vissa är skiftlägeskänsliga och andra inte).

Tabellnamn är också singular . Namnet på tabellen namnger vad en rad av tabellen representerar. Vi inkluderar inte heller _table som en del av namnet.

Kolumnnamn i MySQL är aldrig skiftlägeskänsliga, men vi använder alltid gemener för kolumnnamnen också. Vi "camelCase" inte våra kolumnnamn, vi använder understreck som avgränsare, t.ex. power_id kontra powerID , hero_name kontra hero_name .

UPPFÖLJNING

Mina "anteckningar" ovan är inte specifika regler som måste följas; det är bara mönster vi använder.

Att följa dessa mönster garanterar inte att vi kommer att ha en framgångsrik programvara, men det hjälper oss.

För din referens ska jag visa hur dessa tabeller skulle se ut som ett "första snitt" från vår butik, som en illustration av ett annat mönster; det här är inte "rätt sätt", det är bara "ett sätt" som vi har bestämt oss för som ett lag.

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;