プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight

おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ

[n314]

ライフサイクルで分割するとnullを排除できる。第6正規化とか。例えばユーザー情報は決まっていないがログイン情報は決まっている、またはユーザー情報は残すがログイン情報は消す、という状態は現実にあり得る。

[kaerucircus]

でも、こういうのはRDBMS側とActiveRecordが賢く効率化すべきで、バッドノウハウとして留意する事だよ

[to_tu]

このあたり

[suginoy]

“このカラムだけを分離した別テーブルにすることも考えられます。”

[csouls]

これこれ

[rochefort]

1対1のテーブル分割

[takaesu]

オートインクリメントを止める、1対1を完全に保証する

[kahki]

[O/Rマッピング][Rails]

[ainame]

ActiveRecord的な話だった

[HIROCASTER]

ふむ… : "プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight"

[decoy2004]

『ライフサイクルで分割するとnullを排除できる。第6正規化とか。例えばユーザー情報は決まっていないがログイン情報は決まっている、またはユーザー情報は残すがログイン情報は消す。 はてなコメント』

[kasumani]

プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 Tags: feedly, ifttt, recently read, saved for later from Pocket March 05, 2014 at 07:2

[deep_one]

意味不明だと思ったら、SQLの話じゃないのね。そりゃ使えるIDがあるなら新設の必要はない。

[nakag0711]

ビューを有効に使いましょう

[uzuki-first]

なるほどー！

[soplana]

ほうほう

[norisu0313]

プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する

[minoru0707]

うちは無条件で、1個のテーブルにぶっこむけどなぁ。古い考え方なんだろうか。

[skyriser]

サロゲートキーなんていらねーぜ！の原理

[sh2]

なるほど

[udzura]

旧いSQL serverなどで1テーブルでのカラム数の制限がある際のテクニック（違

[nekoruri]

本題とずれるけど、joins/mergeは確かにパワフル。

[kamipo]

これはよくやる

[lizy]

でかい列・アクセス頻度の低い列を分割する。DBのキャッシュ的にも有利なのかな

[kitokitoki]

has_oneでforeign_key: 'id', ActiveRecord::Store