3

ユーザー通知のためにデータベースを非正規化する必要があると思います。たとえば、投稿にフラグを立てる場合 (ユーザーが考慮する必要があります)、flag ENUM('yes', 'no')(またはステータス列) の列を追加します。の WHERE 句を使用してカウントすることにより、ユーザーのフラグ付きイベントを見つけることができますuser_id='XX' AND flag='yes'。

この正規化された構造は問題ありません。しかし、さまざまな種類の通知がある場合はどうでしょう。例: 投稿、コメント、写真のフラグ ... これは、ユーザーが自分のプロフィール ページにアクセスしたときに、いくつかのテーブルをカウントする必要があることを意味します。これは、さまざまなサイトの通知を受け取るため、stackexchange のようなクロス プロジェクトではより深刻です。

非正規化は、通知列をユーザーテーブルに追加するのに役立つと思います

post_flags tinyint(3),
comment_flags tinyint(3),
photo_flags tinyint(3),

この場合、対応するすべてのアクションでユーザー フラグ列を更新するために、追加の書き込みクエリを実行する必要があります。たとえば、投稿にフラグを立てる場合: UPDATE users SET post_flags=post_flags+1 WHERE user_id='XX'. 私の懸念は、後者のクエリを確実に実行して、この数とフラグが立てられた投稿の数との不一致を回避することです。で確保できると思いますTRANSACTION。

このようにして、頻繁にアクセスするプロファイル ページの 1 つのクエリですべての通知を取得します。

私は正しい軌道に乗っていますか？または、この目的のために別のトリッキーなアプローチが一般的ですか?

4

3 に答える 3

1

おそらく、ユーザー通知の表を使用したほうがよいでしょう。

create table user_notifications (
  user_id integer primary key, -- ? references users, not shown
  post_flags unsigned tinyint(3) not null default 0,
  comment_flags unsigned tinyint(3) not null default 0,
  photo_flags unsigned tinyint(3) not null default 0
);

別の狭いテーブルは、論理的であり、(おそらく) 高速です。負の数には意味がなく、MySQL は CHECK 制約を適用しないため、フラグは符号なしです。

正規化に関する限り、user_notifications は 5NF にあります。

于 2012-03-04T15:03:14.240 に答える
1

これはまったく正規化されていませんか？これらの 3 つの列を作成することは、整理するためのより良い方法であり、私にはより普通のように思えますか?

于 2012-02-28T13:30:13.307 に答える
0

これはあまり効果的ではないと思います。post_flags OR comment_flags OR photo_flags など、フラグの組み合わせも検索する必要があり、クエリの順序も重要な場合に便利です。

于 2012-02-28T13:34:19.597 に答える