составной первичный ключ и уникальный ключ как внешний ключ - PullRequest
Новая
       19

составной первичный ключ и уникальный ключ как внешний ключ

1 голос
/ 26 декабря 2011

Хорошо. Вот ситуация.

  • В университете более одного факультета.
  • Каждый факультет имеет более одного отделения.

Я не хочу дублирования факультетов или кафедр. Итак, я определил три таблицы ниже. 

CREATE TABLE university (
    id INT PRIMARY KEY AUTO_INCREMENT,
    long_name VARCHAR(255) UNIQUE NOT NULL,
    name VARCHAR(255) NOT NULL,
    country VARCHAR(45) NOT NULL,
) Engine=InnoDB;

CREATE TABLE school_faculty (
    id INT UNIQUE NOT NULL AUTO_INCREMENT,
    name VARCHAR(45),
    universityID INT,
    PRIMARY KEY (name, universityID),
    FOREIGN KEY (universityID) REFERENCES university (id)
) Engine=InnoDB;

CREATE TABLE department (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(45) NOT NULL,
    schoolfacultyID INT NOT NULL,
    FOREIGN KEY (schoolfacultyID)
        REFERENCES school_faculty (id)
) Engine=InnoDB;

Пожалуйста, скажите мне, если это неправильно или есть лучший способ. Я борюсь с этим и вроде как беспомощен.

Ответы [ 2 ]

0 голосов
/ 26 декабря 2011

У вас все хорошо, кроме таблицы school_faculty.Было бы лучше использовать следующую схему: 

CREATE TABLE school_faculty (
    id PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(45),
    universityID INT,
    UNIQUE (name, universityID),
    FOREIGN KEY (universityID) REFERENCES university (id)
) Engine=InnoDB;

Лучше использовать целочисленный столбец в качестве PK вместо составного ключа.В таблицах InnoDB PK представляет собой кластерный индекс , поэтому использование наименьшего типа данных для PK означает, что MySQL может считывать больше данных из индекса за сканирование.В большинстве случаев лучше, чтобы первичный ключ имел автоинкремент, что позволяет легко упорядочить (они в основном уже упорядочены).

Кроме того, вторичные (некластеризованные) индексы хранят данные с ПК.Использование меньшего типа означает, что вторичные индексы занимают меньше места.Любой запрос, использующий вторичный индекс, должен использовать PK для доступа к фактическим данным строки, поэтому он будет использовать все, что сокращает время доступа через PK.

Вы также должны добавить уникальный ключ для отдела (имя, schoolfacultyID) для предотвращения дублирования кафедр на данном факультете.

Надеюсь, это поможет.

0 голосов
/ 26 декабря 2011

Выглядит хорошо.

Вы могли бы немного нормализовать ситуацию, имея таблицу с просто ошибочными названиями / отделами, и преобразовать ваши таблицы отделов / ошибок в (UniversityID, facultyNameID).Но этот уровень нормализации, вероятно, излишний.Хотя весьма вероятно, что во всех университетах существует более одного факультета физики или плетения корзин, несколько лишних байтов, которые вы бы использовали, храня в таблице несколько копий слова «физика», не сломают банк.

То же самое относится и к отделам, и то же самое, "вероятно, не проблема".

...