SQL Връзка много към много между множество таблици

Да, там всичко изглежда наред. Но...

Няколко бележки:

Бихме използвали по-кратък тип данни за gender колона; Не виждам, че ще ни трябват 255 знака, за да изразим това. (Има ограничение за максималния размер на ред, който се прилага.) Ако има само няколко стойности за това, ще разгледаме ENUM тип данни.

Вероятно бихме добавили и NOT NULL ограничения за няколко от тези колони, като име на герой, собствено име, фамилия. Вероятно бихме добавили и DEFAULT '' . Понякога наистина трябва да разрешим NULL стойности по някаква причина, но използваме NOT NULL където можем.

Колебая се относно TEXT колони. Няма нищо лошо в използването на TEXT тип данни, но просто се съмнявам, че те може да „скриват“ някаква информация, която може да се съхранява по-добре в допълнителни колони.

За външните ключове ще присвоим име на ограниченията, следвайки модела, който използваме, и също така вероятно ще добавим ON UPDATE CASCADE ON DELETE CASCADE

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

Бележка за идентификаторите (имена на таблици и имена на колони)

По начина, по който го правим, всички имена на таблица са малки букви . (Имаме набор от опции за MySQL, който принуждава всички имена на таблици да се записват с малки букви.) Правим това, за да избегнем проблеми с несъвместимостта за различни операционни системи/файлови системи (някои от които са чувствителни към главни букви, а други не).

Освен това имената на таблици са единствено число . Името на таблицата назовава какво един ред на таблицата представлява. Ние също не включваме _table като част от името.

Имената на колоните в MySQL никога не са чувствителни към малки букви, но ние винаги използваме малки букви и за имената на колоните. Ние не "camelCase" имената на нашите колони, ние използваме символ за долно черта като разделители, напр. power_id срещу powerID , hero_name срещу heroName .

ПОСЛЕДВАНЕ

Моите „бележки“ по-горе не са конкретни правила, които трябва да се спазват; това са просто модели, които използваме.

Следването на тези модели не гарантира, че ще имаме успешен софтуер, но ни помага.

За ваша справка ще покажа как тези таблици биха изглеждали като „първо изрязване“ от нашия магазин, като илюстрация на друг модел; това не "правилният път", това е просто "начин", на който сме се спрели като екип.

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;