私はRubyonRailsアプリを作成していますが、Userクラスが多くのジェネリックブール/整数属性で終わる可能性があることに気づいています。たとえば、四半期ごとにプロモーションがあり、そのプロモーションを1人だけが使用できるようにしたいとします。次に、そのプロモーションを追跡するために、四半期ごとにhas_used_promotion_Nの新しい列を作成する必要があります。
または、アカウントに設定されたフラグのカンマ区切り値である「GenericFlags」という新しい列を作成することを考えています。例えば：
「has_used_promotion_1、has_used_promotion_2、limit_on_feature_a = 20」などは、特定のユーザーに設定できます。
（または、JSONとして保存するかもしれません）
いずれにせよ、私は自分のDBにある種のNoSQLのような機能を自分自身に与えることを考えています。
これはどういうわけか本当に悪いデザインですか？他の誰かが以前にこれをしたことがありますか？RoRについて完全に欠けているものはありますか？
私の意見では、プロモーションは、ユーザーとの多対多の関係を持つ別個のモデルである必要があります。プロモーションがある場合は、プロモーションインスタンスを作成し、ユーザーがそのプロモーションを使用する場合は、そのユーザーをpromotion.users関係に追加します。
これらの関係を照会できるようになったため、これはあなたのアイデアよりもはるかに優れています。第1四半期のプロモーションを使用したすべてのユーザーのリストが必要ですか？問題ない。あなたはあなたの解決策でそれをすることができます、しかしあなたはそれをするためにいくらかのハックネス（それは単語ですか？）に頼らなければなりません、そしてあなたはすべてのクエリですべてのユーザーの一般的なフラグ文字列を解析しなければなりません。控えめに言っても理想的ではありません。
任意のサイズの関連付けのコレクションがある場合、それは既存のDBと機能を使用してモデル化された実際の関係である必要があります。プロモーションはそのように聞こえますが、それはすでにDBでモデリングしているもののようです。重複する値の階層を維持する本当の理由はありません。
実際に-genericフラグの場合、named-flagテーブルを作成し、実際の関連付けを再度使用できます。
couldまた、フラグオブジェクトをテキスト列にシリアル化するだけです。ただし、そうすると、フラグ/フラグ値で簡単な検索を実行できなくなります。これは、ログインしていない限り気にしない単一のユーザーに関連付けられたフラグの束には関係ないかもしれませんが、軽く踏みます-ユースケースによって異なります。