DB板自治・質問・雑談スレ

535 ：NAME IS NULL：2007/05/11(金) 11:32:41 ID:jkj6gZo6

>>531
主キーの話はあくまでをビジネスキーを主キー（複合キー、not null、unique）にして
重複を防ぐということができないといことの説明に書いたもので、このケースでは主キーは
代理キーになります。
>>526参照のこと

テーブル設計についてですが、要件が仮に１時間ごとの予約であれば、
予約テーブル（予約ID、会議室ID、開始時間、使用者（ID））
（もしくは予約テーブルと予約詳細テーブルに分ける）のような感じになりますが、
予約時間の単位が細かくなり、かつ長時間連続で予約するシステムでは多くのレコードを
消費することになる（仮に１５分単位の予約で４時間連続で予約した場合、
実質的にひとつの予約に１６レコードが必要になる）ので、要件、メリット、デメリットの
トレードオフによりテーブル設計することになるのでは？
そしてこの場合のテーブル設計はこれで大きく外していないのではないでしょうか。
仮にこのテーブル設計がひどいものだとしても、あくまでこれは例です。

トランザクションの分離レベルは大きくのデータベースのデフォルトである
リードコミッテッドを想定していました。明記しなかったことをお詫びします。
また、このトランザクションをシリアライザブルに設定して対応する方法を
記入しなかったこともお詫びします。
ご存知のことと思いますが、ＳＱＬ９２の規定は直感的なシリアライザブルを
保証するようには書かれておらず、実際に直感的なシリアライザブルを保証しない
実装も存在する（オープンソース二雄の一つ、ポスグレがそうです）ことや、
リピータブルリード、シリアライザブルは現場であまり使われないだろうとの
勝手な思い込みにより、書かなくても意図を理解してもらえると思ってしまったのです。

続く