「SQLアンチパターン」を避けるためのチェックリスト②（DB物理設計編） - log4ketancho
引き続き「SQLアンチパターン」について、自分なりのチェックポイントを言語化していきたいと思います。下記の記事の続きです。 www.ketancho.net 本題に入る前に、ふたつ。嬉しかったこととお詫び（？）を。 t_wada さんからコメントを頂けた😂 素晴らしいエントリをありがとうございます。『SQLアンチパターン』は名著であると胸を張って言えます。ご興味をお持ちの方はこの機会にぜひ。 / “「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log…” https://t.co/Vjj0Yh2cqU— Takuto Wada (@t_wada) 2018年3月8日 スーパーなエンジニアの方からコメントをいただけるなんてと、帰り道ニヤニヤしてましたｗ 色々拙い部分があると思いますが、自分の理解のために拙くてもいいので言語化を続けていこうと思っています。引き
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
