外部キー制約は重荷になるか - iakioの日記
SQLアンチパターン 4章 キーレスエントリ(外部キー嫌い)より 外部キー制約によって、多少のオーバーヘッドが生じるのは事実です。しかし、以下にあげるように、他の選択肢と比べると、外部キーの方がより効率的であることがわかります。 本書では、外部キー制約を使うことによってデータを更新する時の事前チェックを省略できるので効率が良いという主張。 とはいえ、データベースは「外部キー制約に違反した」というエラーは返してくれるが、複数の制約がある場合にそこからどの外部キー制約に違反したかを取得する一般的な方法は無いので、ユーザーに詳細なエラーの内容を提供する必要がある場合は、やはり事前チェックが必要になる。 あるいは筋が悪いけど、頑張ればどの制約に違反したかをエラーメッセージから拾えるかもしれない。いちいち自分で書く気にはならないが、そういうライブラリがあったら面白そうだ。 MySQLの例 ERROR
そろそろ履歴データについて真面目に考えてみていいんじゃないの - iakioの日記
WEB+DB PRESS Vol.75の「理論で学ぶSQL再入門/履歴データとの上手なつきあい方」が面白かったと感想を書こうと思っていたらもうVol.76が出そうなのでいい加減慌てて書きます。 さてこの記事では、リレーショナルモデルが苦手とするデータ構造の1つとして履歴データを挙げています。 もしかすると「履歴データ」であるということを気づかずにデータベースの設計、クエリの記述をしたことがあるかもしれません。 この記事ではショッピングサイトの価格表を例としています。 価格表が常に現在の価格のみを扱うのであれば問題ありませんが、ある期間に価格を変えたことも価格表に含めるのであればそれは「履歴データ」となります。記事から一部引用するとこんな感じ item price start_date end_date 懸垂マシーン 18000 2010-01-01 2011-12-31 懸垂マシーン 20
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
