子テーブルを制約する親テーブルに制約をどのように作成しますか？

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テーブルにデータベースの制約を作成して、親entity_type-entity_status自体が有効でないfile_type-file_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 
); 

いずれかの線に沿って何かがファイルステータスのために働くだろう。

2番目の場合は、外部キー参照をID番号（スペースの節約、追加の結合が必要）またはステータステキスト（空き領域が多く、結合が不要）に設定できます。ステータステキストには一意制約が必要であることに注意してください。元のデザインでは、ユーザーは同じテキストを複数回入力することができます。 （entity_type.nameが「ファイル」の30行で終わる可能性があります。

Answer 2

トリガーを使用する必要があります。
MySQLは、あなたが望むものを妨げるフォームの制約をサポートしていません。