2

ここでの最初の質問:

現在、3 つの異なるエンティティを使用する必要があるプロジェクトに取り組んでいます。これらのエンティティは、ユーザー、会場、および施設です。

各エンティティにはテーブルがあります。

施設表:

CREATE TABLE `facility` (
`facility_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`venue_id` INT(10) UNSIGNED NOT NULL,
`name` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
`surface` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
`max_timeblock` INT(10) UNSIGNED NOT NULL,
`min_timeblock` INT(10) UNSIGNED NOT NULL,
`availability` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`facility_id`),
UNIQUE INDEX `facility_id` (`facility_id`),
INDEX `facility-venue_id_key` (`venue_id`),
CONSTRAINT `facility-venue_id_key` FOREIGN KEY (`venue_id`) REFERENCES `venue` (`venue_id`) ON UPDATE CASCADE ON DELETE CASCADE)

会場表：

CREATE TABLE `venue` (
    `venue_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `description` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `email` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `phone` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `opening_time` TIME NOT NULL,
    `closing_time` TIME NOT NULL,
    `booking_conditions` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `booking_method` INT(10) UNSIGNED NOT NULL,
    `status` INT(10) UNSIGNED NULL DEFAULT NULL,
    PRIMARY KEY (`venue_id`),
    UNIQUE INDEX `venue_id` (`venue_id`)
)

ユーザー表:

CREATE TABLE `user` (
    `user_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'This field will hold the Unique ID for each user.',
    `username` VARCHAR(50) NOT NULL COMMENT 'This field will be classed as a display name for the users so when searching they arent looking for the ID.' COLLATE 'utf8_unicode_ci',
    `email` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `password` VARCHAR(128) NOT NULL COLLATE 'utf8_unicode_ci',
    `first_name` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `last_name` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `facebook_id` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8_unicode_ci',
    `user_type_id` INT(10) NULL DEFAULT NULL,
    `postcode` INT(10) NULL DEFAULT NULL,
    `status` INT(10) NULL DEFAULT NULL,
    `date_created` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
    `date_modified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`user_id`),
    UNIQUE INDEX `username` (`username`),
    UNIQUE INDEX `email` (`email`),
    UNIQUE INDEX `user_id` (`user_id`)
)

そのため、メディアテーブルを実装しようとしています。

このテーブルの例を以下に示します。

CREATE TABLE `media` (
    `media_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `album_id` INT(10) UNSIGNED NULL DEFAULT '0',
    `alt_name` VARCHAR(50) NOT NULL DEFAULT '0' COLLATE 'utf8_unicode_ci',
    `mine_type` VARCHAR(50) NOT NULL DEFAULT '0' COLLATE 'utf8_unicode_ci',
    `url_link` VARCHAR(50) NOT NULL DEFAULT '0' COLLATE 'utf8_unicode_ci',
    PRIMARY KEY (`media_id`),
    INDEX `media-album_id_key` (`album_id`),
    CONSTRAINT `media-album_id_key` FOREIGN KEY (`album_id`) REFERENCES `album` (`album_id`) ON UPDATE CASCADE ON DELETE CASCADE
)

私が望むのは、ユーザー、施設に1つの画像を関連付け、会場にアルバムを関連付けることを許可することです。

そのため、この点で外部キーを実装する方法がわかりません。メディアの列をユーザーテーブルに配置し、Media_ID に外部キーを設定すると、メディアを削除すると、カスケードの影響によりユーザーが削除されるためです。

私が望むのは、ユーザー/施設/会場を削除すると、それに関連付けられているすべての画像が削除されることです。

任意の支援をいただければ幸いです。

よろしく、

ロバート

4

1 に答える 1

0

トリガーを使用せずにやりたいことを直接行うことはできないため、最初のオプションとしてここにリストし、実際には避けるべきであるが、このパターンの問題をさらに調査する方法の手がかりを与える2番目のオプションをリストしました.

  • 各施設/会場/ユーザーからmediaテーブルへの外部キーを保持しますが、参照アクションでON DELETE SET NULLはなく使用しON DELETE CASCADE、関連するメディアの削除をアプリケーション コード (またはトリガー) に実装します。
  • 「ポリモーフィック アソシエーション」と、それがリレーショナル データベースではなぜ悪い考えなのかを調べてください。それでもやりたいと確信している場合は、利用可能な手法の 1 つを使用して、考えている逆の関係を構築してください。
于 2013-09-06T11:39:18.773 に答える