1

id列、user、およびその他の多数の列を含むテーブル構造があります。ユーザーが通知を受け取りたい日を選択するように選択する必要がありますが、その方法について決めることができません。

既存のテーブルにさらに 7 つの列を追加したくありません。それは悪い習慣のように思えるからです。

別のテーブルを追加して、これら 2 つをリンクすることを考えましたが、これには既存のコード の多くのやり直しが含まれます (そして、このソリューションを提供する速度が重要な要素です)。

また、たとえば、基本的に月曜日と金曜日1000100に通知を受け入れることを意味する、たとえば7文字の文字列を持つ既存のテーブルに1列だけ追加することも考えました（ポイントを取得します-1または0の位置配列は、その日に通知をその電子メールに送信する必要があるかどうかを決定します。

あなたなら何をしますか？

4

3 に答える 3

2

別のテーブルを追加する必要があります。単純なテーブルを1つ追加するのが大変な場合は、何か問題があります。

create table user_notification_preference (
  user_id bigint not null references user (id),
  day_of_week smallint not null check (day_of_week between 0 and 6),

  primary key (user_id, day_of_week)
);
于 2012-08-29T10:37:11.627 に答える
1

こんなことしないで：

また、たとえば、既存のテーブルに 1000100 のような 7 文字の文字列を持つ列を 1 つだけ追加することも考えました。これは、基本的に月曜日と金曜日に通知を受け入れることを意味します (ポイントを取得します-1 または 0 の位置配列は、その日に通知をその電子メールに送信する必要があるかどうかを決定します。

C# プログラムではなく、リレーショナル データベース環境で作業している場合、列にロジックやコードを配置している場合は、何か問題があります。

ユーザーIDと、通知を受け取る予定の日付または曜日を持つ新しいテーブルを導入するだけです。単純な1対多の関係です。

于 2012-08-28T20:24:52.647 に答える
0

編集

以下は私の最初の答えです、そして私は今それがどれほど悪いかを理解しています。このパターンに従わないでください。削除しますが、多くの場所で見たので、一般的なアンチパターンである必要があります。私はそれを維持していますが、この警告は使用しないでください。これにより、将来の訪問者は、私が今しているように、なぜこれが悪いのかを知ることができます。

Neil McGuinanがこの回答にコメントして以来、私が読んだすべての専門家のアドバイスは、彼のアプローチがより良いものであることを示しています。理由を説明する良い記事が1つあります：http：//geekswithblogs.net/darrengosbell/archive/2006/03/12/KVPsInDatabaseDesign.aspx

私たちのソリューションが「私たちのために働いた」理由は、KVPデータをピボットして、期待する構造（属性の列）を持つテーブルを生成するプロセスがあったためです。これは、設定時に属性の列を含む別のテーブルを作成したときにこれを知っていれば回避できたはずの不要なオーバーヘッドです。あなたは私たちがたどった道を進みたくありません。散らかっています。

/編集

私はAttributesという名前の新しいテーブルを設定し、次にCustomerAttributesという名前の中間（外部キー）テーブルを設定しました。そうすれば、顧客に属性を追加するために列を再度追加する必要はありません。

属性：

AttributeId   AttributeName
-----------------------------
1             PreferredNotificationDayOfMonth
2             FavoriteColor
etc...

CustomerAttributes

CustomerId   AttributeId   AttributeValue
1            1             5
1            2             Blue
2            1             1
2            2             Red

理由:(レイマンの説明）列を変更することは、データベーステーブルにレコードを追加するよりもはるかにリスクが高いため、属性を列ではなく行にシフトできる場合は、将来のメンテナンスの問題を軽減できます。

于 2012-08-28T20:24:39.760 に答える