【Rails関西】Rails屋からデータモデリングに対する回答
1/20に開かれた第6回RubyOnRails関西へ行ってきた。
場所は神戸電子専門学校。目の前にオランダ館、風見鶏館などの異人館があり、華やかな場所でした。
このたびの発表の中で最も興味を引いた講演が「やさしいRailsの育て方」(by 西和則さん)。
講演内容は、Railsでもテーブル設計をきちんと考えましょう、ということなのだが、それは昨年8月の渡辺さんの指摘に対する回答になっているように思う。
【1】RDBのテーブル設計におけるアンチパターン
Railsをやっていると、例えば、下記のアンチパターンに囚われてしまう。
1・無限FK地獄や列破綻
テーブルに他テーブルの外部キーをどんどん持たせると列が増えていく。
西さんの例では、社員テーブルに派閥1、派閥2のカラムを増やしていた。
2・フラグステータスとバタフライ効果
「北京で蝶が羽ばたくとニューヨークで嵐が起きる」がその意味だが、「小さな変更による影響の範囲が大きくなる」ことのたとえ。
西さんは、社員テーブルと企業テーブルに論理削除のカラムがあった場合、フラグが少しだけ変わるだけで表示されなくなる例を持ち出していた。
テーブルを設計した時、上記のような状況に陥ったことはありませんか?
【2】現在のトレンドは関係テーブル(対照テーブル)を持たせる
アンチパターンに対する対策として、西さんははぶさんの本「楽々ERDレッスン」を参考にして、下記のやり方を紹介していた。
1・対象の独立性
他テーブルと外部キーを持たないようにする。
つまり、アイデンティファイアを導入し、イベント系テーブルは関係テーブル(対照テーブル)として作る。
2・対象の健全性
必要最小限で、余分な情報は持たない。
特にリソース系テーブル。
このやり方を彼らしい例え話で説明していた。
1・アイデンティファイアの意味
複合キーにわざわざアイデンティファイアを導入するのは違和感があるけれど、これは今のメールアプリのタグ付けに似ていませんか?と。
つまり、メールボックスにあるメールのデータは地面に全て置いておき、データを組み合わせてタグをつけて関係付けている。
一昔前のメールアプリは、メールとディレクトリが紐づいていたからわざわざリファイルしていた。
前者はアイデンティファイア、後者は外部キーで紐づいていたのと同じではないか?と。
2・「この項目は火星に飛ばせるか?」で判断する
リソース系テーブルのカラムを分けていく基準として「このカラムは火星に飛ばせるか?」で判断しようと彼は言う。
ドラゴンボールなら、名前・キャラ・生息地・生年月日・パワーなどのうち、生息地は火星に持って行けないから、独立させようとか。
「第7正規形を作りました!」という内容は面白かった。
【3】Railsのメソッド拡張
上記の内容は、1:n、n:nの関係をどう表現するか、と言う問題に帰結する。
そこで、西さんは、Railsのメソッドを拡張していた。Railsのデフォルトになるのだろうか?
(詳細は西さんの発表資料を読んで下さい)
昨年8月の渡辺さんが、Railsはデータモデリングに弱いのではないか?と発言されていたが、Rails屋さんがそれに対して回答していると言う意味で、価値ある講演だった。
| 固定リンク
| コメント (0)
| トラックバック (0)
最近のコメント