RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳
Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBアンチパターン // Speaker Deck
『Cassandraのデータ設計で注意していること』
