SQL Relacja wiele-do-wielu między wieloma tabelami

Tak, wszystko tam wygląda w porządku. Ale...

Kilka uwag:

Użylibyśmy krótszego typu danych dla gender kolumna; Nie wydaje mi się, żebyśmy potrzebowali 255 znaków, żeby to wyrazić. (Istnieje limit maksymalnego rozmiaru wiersza, który jest wymuszony.) Jeśli jest tylko kilka wartości, rozważymy ENUM typ danych.

Prawdopodobnie dodamy również NOT NULL ograniczenia dotyczące kilku z tych kolumn, takie jak heroname, name, lastname. Prawdopodobnie dodamy również DEFAULT '' . Czasami z jakiegoś powodu naprawdę musimy zezwolić na wartości NULL, ale używamy NOT NULL gdzie tylko możemy.

Waham się co do TEXT kolumny. Nie ma nic złego w używaniu TEXT typ danych, ale podejrzewam, że mogą one „ukrywać” niektóre informacje, które lepiej przechowywać w dodatkowych kolumnach.

W przypadku kluczy obcych przypisalibyśmy nazwę ograniczeniom zgodnie ze stosowanym przez nas wzorcem, a także prawdopodobnie dodaliśmy ON UPDATE CASCADE ON DELETE CASCADE

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

Uwaga na temat identyfikatorów (nazwy tabel i nazw kolumn)

Sposób, w jaki to robimy, wszystkie nazwy tabel są małe . (Mamy ustawioną opcję MySQL, która wymusza stosowanie małych liter we wszystkich nazwach tabel.) Robimy to, aby uniknąć problemów z niekompatybilnością różnych systemów operacyjnych/systemów plików (niektóre z nich uwzględniają wielkość liter, a inne nie).

Ponadto nazwy tabel są pojedyncze . Nazwa tabeli określa, co jeden wiersz tabeli reprezentuje. Nie uwzględniamy również _table jako część nazwy.

W nazwach kolumn w MySQL nigdy nie jest rozróżniana wielkość liter, ale zawsze używamy również małych liter w nazwach kolumn. Nie używamy "camelCase" naszych nazw kolumn, używamy znaku podkreślenia jako separatorów, np. power_id w porównaniu z powerID , hero_name kontra heroName .

KONTYNUACJA

Moje „notatki” powyżej nie są konkretnymi zasadami, których należy przestrzegać; to tylko wzorce, których używamy.

Stosowanie się do tych wzorców nie gwarantuje, że będziemy mieli udane oprogramowanie, ale nam to pomaga.

W celach informacyjnych pokażę, jak te stoły wyglądałyby jako „pierwsze cięcie” z naszego sklepu, jako ilustracja innego wzoru; to nie „właściwy sposób”, to po prostu „droga”, na którą zdecydowaliśmy się jako zespół.

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;