Это адекватный первичный ключ?

Question

У меня есть таблица Событий и несколько подтаблиц различных типов для определения каждого события.

Таблица событий имеет идентификатор, (возможно, не уникальный) Datetime, userId и тип события.

Для таблиц типов событий, скажем, ExerciseStart ... является ли EventId адекватным первичным ключом?Каждое событие имеет только один тип, поэтому оно никогда не должно удваиваться.И полезно ли включать datetime в подкатегории, даже, возможно, в качестве составного первичного ключа, чтобы избежать случайного удвоения и потенциально облегчить написание запросов?(хотя это также было бы излишним).

(Если бы я не использовал Datetime и тип события в качестве составного ключа, но мне это кажется более рискованным)

Answer 1

Использование стандартного SQL ...

Обычный способ сделать «наследование» или «подклассы» - это составной ключ на (event_type, event_ID) и использовать этот ключ в ссылочных таблицах «подтипа» сCHECK ограничение для обеспечения того, что event_type подходит для этого «подтипа», например, CHECK (event_type = 'Exercise start').

Дополнительным штрихом является то, чтобы event_type DEFAULT в таблице 'subtype' снова соответствовал соответствующему типу, например event_type VARCHAR(20) DEFAULT 'Exercise start' NOT NULL.

Структура может выглядеть следующим образом:

CREATE TABLE EventTypes 
(
 event_type VARCHAR(20) NOT NULL PRIMARY KEY
);

CREATE TABLE Events 
(
 event_ID CHAR(10) NOT NULL, 
 event_type VARCHAR(20) NOT NULL
    REFERENCES EventTypes (event_type), 
 event_date DATE NOT NULL, 
 PRIMARY KEY (event_type, event_ID)
);

CREATE TABLE ExerciseStartEvents 
(
 event_ID CHAR(10) NOT NULL, 
 event_type VARCHAR(20) DEFAULT 'Exercise start' NOT NULL
    CHECK (event_type = 'Exercise start'), 
 FOREIGN KEY (event_type, event_ID)
    REFERENCES Events (event_type, event_ID), 
 PRIMARY KEY (event_type, event_ID), 
 exercise_description VARCHAR(30) -- etc --
);

Однако существует большая проблема с MySQL, заключающаяся в том, что он не применяет ограничения CHECK :( [То, как кто-либо может допустить эту ситуацию, мне не под силу!] Поэтому, чтобы ответить на ваш вопрос, имея простой ключ на event_ID одного недостаточно, потому что вы не можете применить соответствующий тип в таблицах «подтипов».

Хотя может быть соблазн «продвинуть» event_ID в качестве ключа-кандидата в таблице подтипов, этоможет не быть хорошей идеей. Хотя это позволило бы отображать в таблице только одну строку для данного event_ID, если эта строка имеет неправильный тип, это предотвратит вставку строки с правильным типом!

Решение? Перейти к лучшей реализации SQL;)

Answer 2

Я думаю, что вам нужно, это называется interitance таблицы классов: у вас есть envent_table, который содержит все общие свойства и множество таблиц для различных типов событий.

Это может быть что-то вроде этого:

CREATE TABLE events(
    event_id SERIAL PRIMARY KEY,
    ... other fields
);

CREATE TABLE event_typeN(
    event_id BIGINT UNSIGNED PRIMARY KEY,
    ...other fields,
    FOREIGN KEY(event_id) REFERENCES events(event_id)
);