makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

SQLアンチパターン読書会 「IDリクワイアド」に参加しました

2013/5/9(木) SQLアンチパターン読書会 「IDリクワイアド」に参加してきました。

DoorKeeper
http://sqlap.doorkeeper.jp/events/3774

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


会場は御徒町(湯島)の株式会社アルティネットさんです。
参加者は10人かな。ディスカッションには最適な人数です。

今回も @t_wada さん参加!更にOracleの @yokatsuki さんまで参加です。贅沢な勉強会ですねー。
私、この日は体調不良で会社をお休みしました。
んで午後6時くらいまで病床に臥していたのですが、気合で勉強会に参加!

今回も、いつもの如くディスカッションしたいテーマを各自で付箋に書き出しました。
20130509_sqlap1.jpg


■IDリクワイアド、という原著のタイトルに対し、翻訳者と「とりあえずID」と日本語訳を決めた。
 → どういうニュアンスでタイトルを伝えようか、といろいろ考えた。

■読者からは11章の「ファントムファイル」と今回の「IDリクワイアド」が一番反響があった。

■IDリクワイアドは使うべきではない!という意見アリ。
 → 論理設計の段階では、IDはすべてに付けないはず。IDリクワイアドは飽くまで物理設計。

■ナチュラルキー、主キー、複合キー、擬似キー、ユニークキー、サロゲートキー。。。いろいろなキーがある。
・主キーがないとけいないと思うのは間違い。
・ユニークキーがないといけない、と思いこむのは間違い
・あった方が便利、というのと、なくちゃいけない、というのは別。

■この3章だけで、DOAの方までこの本がリーチしたのが面白いところ。渡辺幸三さんまで!



■自然キーとは?
・社員番号とか健康保険番号とか、実際の世界で使われている識別子。
・ユニークとは限らない。
・どれを自然キーとするかが論理設計そのもの。

■ユニークキーとは?
・ユニークキーは、ユニークであるだけであって、主キーとは別。
・ユニークキーは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リクワイアドについて引き続きディスカッションします。

体調不良ながら参加した甲斐がありました。でも、帰りの電車、間違えた。。。



最後に、参加者の皆様ありがとうございましたー。
関連記事
スポンサーサイト

コメント

大変興味深いです

IDリクワイヤードの議論とても興味深いです。
そういえば某⚪︎BM社の設計で自然キーのテーブルに必ずIDをユニークインデックスとしてキーとは別に定義している物を見たことがあります。アレはアレで一つの落とし所かなと

  • 2014/09/19(金) 23:59:18 |
  • URL |
  • ハニーQ #sSHoJftA
  • [ 編集 ]

Re: 大変興味深いです

ハニーQさん、コメントありがとーございます。
IDリクワイアドの回はかなりディスカッションが盛り上がりました。
ちなみに先日の勉強会でやった21章「シュードキー:ニートフリーク(疑似キー潔癖症)」も、キー設計がテーマでした。
http://makopi23.blog.fc2.com/blog-entry-147.html

  • 2014/09/20(土) 19:16:38 |
  • URL |
  • makopi23 #.L9CjpiI
  • [ 編集 ]

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/73-a0c0e002
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad