STIとMTIの違いと別のテーブルとの比較

Question

私は、deviseを使って認証するためのrails 3.1プロジェクトを持っています。

私はいくつかのユーザータイプを持っていますが、それぞれは実際にはデータベースのフィールドが非常に異なっています。私はそれぞれ異なるモデルを用意していましたが、メッセージングのようなモデル間で機能が重複していて、単一のモデルを持つのが理にかなっていました。これは特に、異なるタイプのユーザー間でメッセージングを処理する場合に問題となりました。

個別のテーブルとしてそれらをすべて残すか、1つのテーブルに移動する必要がありますか？複数の表の継承は、ユーザーを常に探しているという事実を考えると、実際にはあまり意味がありません。それは単に賢明に参加するには高価すぎるだろう。

テーブル内の各ユーザータイプのすべての未使用の列を持つことは、実際には汚いと感じます。

思考？

Answer 1

個人的に私は、未使用のカラムはそれほど大したことではないと思いますが、本当にあなたを悩ますなら、あなたは非正容の解決策を試してみるとよいでしょう。あなたの異なるタイプのユーザーに共通ではないすべての属性を「バケツ」とみなしましたか？私はattr_bucketのようなプラグインの使用について話しています。

基本的にあなたがあなたにDBテーブルを午前余分な列を追加します。

t.text :non_common_attributes 

そして、（一般的なクラスから継承）あなたの異なるユーザーモデルのそれぞれに、あなたのようなものだろう：

class UserType1 < User 
    attr_bucket :non_common_attributes => [:first, :second, :third] 
end 

class UserType2 < User 
    attr_bucket :non_common_attributes => [:fourth, :fifth] 
end 

を

通常の方法で定義したのと同じように属性を使用しますが、モデルをデータベースに保存すると、それらの属性はすべてYAML経由でシリアル化され、:non_common_attributes列に格納されます。モデルを再度ロードすると、モデルは透過的に逆シリアル化されます。

バケツアトリビュートでインデックスを作成することができないため、バケット属性を使用してユーザーを検索したくないなどのいくつかの注意点がありますが、あなたが何をしているのかシリアライズとデシリアライズのコストについてはあまり心配しませんが、同時に何千ものユーザーをセーブ/ロードする可能性は低いので問題にはならないでしょう。

Infactでは、ほとんどの属性を暗号化する必要のあるモデルで、似たようなソリューションを使用しています（しかし、宝石を使用するのではなく手作業でロールしました）。私はすべての属性をまとめてバケツを暗号化するだけです。