Как создать ограничение на родительские таблицы, которое также ограничивает дочерние таблицы?

Question

Я не уверен, как сформулировать вопрос, поэтому я проиллюстрирую таблицы и объясню, чего я хочу достичь.

-- static table of the entity classes supported by the application
create table entity_type (
  id   integer     not null auto_increment,
  name varchar(30) not null,

  primary key(id)
);

-- static table of statuses supported by the application
create table entity_status (    
  id   integer     not null auto_increment,
  name varchar(30) not null,

  primary key(id)
);

-- table of valid combinations 
create table entity_type_entity_status_link (    
  entity_type_id   integer not null,
  entity_status_id integer not null,

  unique key(entity_type_id, entity_status_id),
  foreign key(entity_type_id) references entity_type(id),
  foreign key(entity_status_id) references entity_status(id),
);

-- The tables where user types and statuses are defined
create table user_type (    
  id             integer     not null auto_increment,
  name           varchar(30) not null,

  entity_type_id integer not null,
  primary key(id),
  foreign key(entity_type_id) references entity_type(id)
);

create table user_status (    
  id             integer     not null auto_increment,
  name           varchar(30) not null,

  entity_status_id integer not null,
  primary key(id),
  foreign key(entity_status_id) references entity_status(id)
);

-- table of valid pairs
create table user_type_user_status_link (    
  user_type_id   integer not null,
  user_status_id integer not null,

  unique key(user_type_id, user_status_id),
  foreign key(user_type_id) references user_type(id),
  foreign key(user_status_id) references user_status(id),
);

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

У меня есть вопрос, что я не могу найти способ создания каких-либо ограничений базы данных для таблицы user_type_user_status_link, чтобыВы не можете вставить пару file_type - file_status, где родительский entity_type - entity_status сам по себе недопустим.Или это то, что должно быть сделано с помощью триггеров.

Answer 1

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

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

Этот подход никогда не заканчивается хорошо.

То, что вы разработали, это "Одна таблица истинного поиска".Google, что по целому ряду причин, почему OTLT является анти-паттерном.

Лучшее решение - моделировать реальные вещи в ваших таблицах.( Сущность не является реальной вещью. Это абстракция реальной вещи.) Что-то вроде

create table file_status (
  file_status varchar(30) primary key
);

или

create table file_status (
  file_status_id integer primary key,
  file_status varchar(30) not null unique
);

будетхорошо работают для статусов файлов.

В случае второго вы можете установить ссылку на внешний ключ либо на номер идентификатора (экономит место, требуется дополнительное объединение), либо на текст статуса (занимает больше места), исключает соединение).Обратите внимание, что вам нужно уникальное ограничение на текст статуса;Ваш оригинальный дизайн позволяет пользователю вводить один и тот же текст несколько раз.(Вы можете получить 30 строк, где entity_type.name - «Файл».

Answer 2

Для этого следует использовать триггеры.
MySQL не поддерживает ограничения формы, которые будут препятствовать тому, что вы хотите.