テーブル間の参照として日付フィールドを使用することは賢明ですか？

Question

私はevent_idでリンクされた2つのテーブルイベントと予約を持っています。 例：それは1バイト少ない整数に比較を消費だと私は思ったんだけど

CREATE TABLE `bookings` (

    `booking_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, 
    `event_id` int(10) UNSIGNED NULL DEFAULT NULL, 
    `fullname` varchar(80) NOT NULL, 
    `phone` varchar(20) NULL DEFAULT NULL, 
    `note` text NULL, 
    `date_created` datetime NOT NULL, 
    `date_updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP, 

    PRIMARY KEY (`booking_id`), 
    FOREIGN KEY (`event_id`) REFERENCES `events` (`event_id`) ON DELETE SET NULL ON UPDATE CASCADE, 

    INDEX `event_id` USING BTREE (`event_id`), 
    INDEX `source_id` USING BTREE (`source_id`) 
) 
ENGINE=InnoDB 
DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci 
ROW_FORMAT=COMPACT; 

    #events 
CREATE TABLE `events` (
    `event_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT , 
    `date` date NOT NULL , 
    `title` varchar(255) NULL DEFAULT NULL , 
    `description` text NULL, 

    PRIMARY KEY (`event_id`, `date`), 
    UNIQUE INDEX `date` USING BTREE (`date`) , 
    INDEX `event_id` USING BTREE (`event_id`) 
) 
ENGINE=InnoDB 
DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci 
ROW_FORMAT=COMPACT; 

は、私は、テーブル間の参照として日付フィールドを使用することができますし、読み込まれ、単一のテーブルではなく、組み合わせで動作するように簡単です。 しかし、インデックスとSQLクエリのパフォーマンスにどのような影響があるのか​​よくわかりません。

Answer 1

テーブル間のリンクとして純粋なデータフィールドを使用することはお勧めできません。 A dateフィールドは直感的に汎用フィールドであるように見えるので、別のエンジニアは最終的には合理的なアプリケーション目的のためにフィールドを更新します。テーブルリンクとして使用された場合、更新によってリンクが解除されます。

テーブルリンケージの目的で特定のフィールドを作成しないのはなぜですか？確かに、レコードあたり4バイトまたは8バイトのコストがかかるかもしれませんが、ストレージのコストを見ていますか？それはほとんど無料です。一方、フィールドの非直感的な使用は、将来のエラー、誤解、混乱、およびダウンタイムで多少の費用がかかるかもしれません。

Answer 2

私はそれをしません。イベントの日付が移動するとどうなりますか？同じ日に2つのイベントがある場合はどうなりますか？

は、あなたはすでにあなたが（EVENT_ID）は変更しないことを知っている生成された自然の鍵を持っているので、それを使用することがはるかに安全です。