DoorKeeper
http://sqlap.doorkeeper.jp/events/3774
以下の書籍をターゲットとした読書会なのです。
 | SQLアンチパターン (2013/01/26) Bill Karwin 商品詳細を見る |
会場は御徒町（湯島）の株式会社アルティネットさんです。
参加者は10人かな。ディスカッションには最適な人数です。
今回も @t_wada さん参加！更にOracleの @yokatsuki さんまで参加です。贅沢な勉強会ですねー。
私、この日は体調不良で会社をお休みしました。
んで午後6時くらいまで病床に臥していたのですが、気合で勉強会に参加！
今回も、いつもの如くディスカッションしたいテーマを各自で付箋に書き出しました。
■IDリクワイアド、という原著のタイトルに対し、翻訳者と「とりあえずID」と日本語訳を決めた。
→ どういうニュアンスでタイトルを伝えようか、といろいろ考えた。
■読者からは11章の「ファントムファイル」と今回の「IDリクワイアド」が一番反響があった。
■IDリクワイアドは使うべきではない！という意見アリ。
→ 論理設計の段階では、IDはすべてに付けないはず。IDリクワイアドは飽くまで物理設計。
■ナチュラルキー、主キー、複合キー、擬似キー、ユニークキー、サロゲートキー。。。いろいろなキーがある。
・主キーがないとけいないと思うのは間違い。
・ユニークキーがないといけない、と思いこむのは間違い
・あった方が便利、というのと、なくちゃいけない、というのは別。
■この3章だけで、DOAの方までこの本がリーチしたのが面白いところ。渡辺幸三さんまで！
おおっ! 『SQL アンチパターン』が渡辺幸三さんまでリーチしている!! 解説ありがとうございます! #sqlap / “サロゲートキーと「とりあえずID」の違い: 設計者の発言” htn.to/55yn5R
— Takuto Wadaさん (@t_wada) 2013年3月25日■自然キーとは？
・社員番号とか健康保険番号とか、実際の世界で使われている識別子。
・ユニークとは限らない。
・どれを自然キーとするかが論理設計そのもの。
■ユニークキーとは？
・ユニークキーは、ユニークであるだけであって、主キーとは別。
・ユニークキーはNULLを許容する。DBMSによって仕様が変わる。
■物理設計とか実装を加味していく段階でIDがほぼすべてのテーブルに出現する、というのはあるが、それは実装に向けた設計の話である。
・その段階までに、キーになりうるものが見つからないのはおかしな話。
・論理設計の段階では「とりあえずID」はないのでは。
■オートインクリメントの主キーだと、テストデータを作成するのが大変。。。
・オートインクリメントのキーが外部キーとして使われていたりする。。。
・開発時点では、各開発者のマシン上に構築したDB上でテストする。
→ そうなると、キー以外のカラムの値は同じなのに、主キーの値だけ各自のDBで異なるカオスな状況に。。。
■「とりあえずID」のような設計をやる人は、表計算ソフトに慣れすぎ。
・Excelのような単調増加の行番号がないと不安。
・集合論でモノを見てない。
・カラムの並び順が思ったようにが並んでくれない、とか言う。
・トランザクションで歯抜けになった番号が気持ち悪い、とか言い出す。
・ビューと構造が合っていないのを嫌がる。
・とりあえずID、の人は、テーブルを表計算ソフトとしか見ていない。
■データベースを2次元と思ってしまうのがだめ。DBは多次元集合。
■データベース設計者（DBA）がきちんとDBを設計するような現場では「IDリクワイアド」とかは起こりにくい。
・ただし、その人がDB設計をやってしまうので、人が育たない弊害はある。
■データ移行で何が辛いかというと、シリアルのキーを移行するのがすごく辛い。
・移行の際に、番号は振替ないといけない場合がある。
・なので、IDリクワイアドは移行が大変。再構築したほうがいいことが多い。
■アプリケーションコードよりDBの寿命の方が長い。
・データは移行しながらずっと使うので。
・データベースよりデータの寿命の方が長い。
■日本年金機構が、性同一性障害で性別変更した人を判別するため、基礎年金番号10桁のうち前半4桁に共通する固定番号として8500を割り当てた事例
年金機構から基礎年金番号の付番機能を剥奪せよ
http://takagi-hiromitsu.jp/diary/20130507.html
→ 炎上後、番号を変えて新たに附番しなおすとした。（さらに炎上）
→ 外部の要因で自然キーを付け替える良い例。
■画面中心設計だと、データの設計から始まらない。
→ それで継ぎ足しでやっていっていろいろおかしくなる。
■デザインの変更とDBの変更は、本来は全く関係がない。
・RDBMSは、デザインの変更に柔軟についていくためにある。
・RDBMSとSQLがあるからデザイン変更についていける。
・結論が逆。デザイン変更が止まらないとDB変更が止まらない。のではなく、デザイン変更を止めたくないからDB設計をする。
・画面は一番寿命が短い。それよりアプリケーションコードの寿命の方がやや長い。
・DBMSの寿命の方ががさらに長い。更に、データの寿命の方が更に長い。
→ デザイン変更の際に、寿命が長い方が影響をうけるのはおかしい。
■画面にデータ項目が追加になった場合に、DBにカラムを単純に足せばいいのか、そうじゃないのかを判断できることが重要。
・変更に対して敏感になることが大事。
・画面の項目数＝テーブルのカラム数、のように画面とテーブル構造を直結して考えちゃうのがそもそもの間違い。
・本来はビューとテーブル設計は別。
■本書で設計の議論が一番出たのがIDリクワイアド。
・フレームワークがIDを振ることがある。その場合は従うべき。
・名言「俺はIDを振ってない！RailsがIDを振ってるんだ！」By 角谷さん
・RailsにとってはIDはポインタの一種。ポインタは意識しないけど存在している。物理設計の際に存在しているのは当たり前。
■プログラムの延長線上で考えるのではなく、データの構造は別として考え切り替える。
・経営から落としていく。経営としてどういう情報が必要か、を考えるのがいいのでは。
■DB設計のサンプルはいっぱいある。英語さえ読めれば。一番有名なのは以下らしい。
database Answers
http://www.databaseanswers.org/data_models/index.htm
→ サンプルが600くらいある。
■IPA情報処理技術者試験のデータベーススペシャリストの午後Ⅱ試験はDB設計の良い題材かも。
・DB周りは、資格が唯一機能を果たしている分野かも。
・モデリングなんで、抽象的に考えられる素質が必要かも。
■プログラムを書く事とDBの設計は切り離して、データをどう扱うか、というコマを1つ用意すべきでは。
・プログラミングの延長としてDB設計を考えると惨状が生まれる。
・データをどう設計するか、というのだけをきちんと教えるのを教育に盛り込むことが必要。
■書籍「データベースリファクタリング」の6章に「自然キーによる代理キーの置き換え」という節がある。
→ 参考になる。
 | データベース・リファクタリング (2008/03/26) スコット W アンブラー、ピラモド・サダラージ 他 商品詳細を見る |
★感想：
話が沸騰して、2時間でIDリクワイアドを語りきれないほど盛り上がりました。
みなさん、IDリクワイアドとかDB設計について、溜まりに溜まった思いがあるようでしたね。
ということで、次回もIDリクワイアドについて引き続きディスカッションします。
体調不良ながら参加した甲斐がありました。でも、帰りの電車、間違えた。。。
お疲れ様でしたー。今日も大変有意義でした。。体調不良で、間違えて一駅前で下車したのにも気付かず、改札を出てからようやく気付いたという。。。orz#sqlap
— makopi23さん (@makopi23) 2013年5月9日最後に、参加者の皆様ありがとうございましたー。
- 関連記事
-
- 『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加しました
- SQLアンチパターン読書会 「IDリクワイアド」に参加しました
- 「XP祭り関西2013」に参加しました
