2012-02-28 5 views
3

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

この正規化された構造は問題ありません。異なる種類の通知がある場合はどうなりますか。例えば投稿、コメント、写真のフラグ...これは、ユーザーが自分のプロフィールページに行っているときに複数のテーブルをカウントする必要があることを意味します。これは、異なるサイトの通知を取得するため、スタックエクスチェンジのようなプロジェクト間で重大です。

私はデ正規化はこの場合

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つのクエリですべての通知を取得します。

私は適切なトラックにいますか?この目的のために別のトリッキーなアプローチが一般的ですか?

+0

'tinyint(3)'には何を保存しますか?複数のエントリがありませんか? –

+0

通知の数。例えば、ポストにフラグを立てると、UPDATEユーザのクエリを実行します。SET post_flags = post_flags + 1 WHERE user_id = 'XX'' – Googlebot

+0

"flag ENUM(' yes '、' no ') ? – Ivan

答えて

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です。

+0

良いデザインですが、ユーザーとuser_notificationsを2つの列に分割することが本当に必要かどうかはわかりません。通知をユーザーの列に追加できるためです。彼らは 'tinyint'なので、テーブル構造(通知がたくさんあっても)は小さくなります。 – Googlebot

+1

テーブル「users」に何でも*追加することができます。それは問題ではありません。あなたが尋ねるべき質問は、これらのフラグがユーザに関する情報を含むかどうかです。明らかな答えは、他のものに関する情報が含まれているということです。 (通知に関する情報)論理的には、それらは別のテーブルに属しています。その狭いテーブルでは、ページに多くの行が収まるようになるため、ディスクからのページ数を減らす必要があります。それは「より速い」ことを意味します。 (私のサンドボックスでは、空のキャッシュを持つ1行を選択するのに約1000倍の速さ - 0.05msと34.5msとの比較) –

1

これは正規化ですか?これらの3つの列を作成する方がより良い方法です。

+0

良い例は、収支です。誰かの取引履歴を調べるのは重く、「残高」を把握することは、見るべき場所が1つしかないことを意味します。私はあなたの軌道にあると思います! – Luc

+1

余分なデータを保存しているので、正規化されていないと思います! – Googlebot

+0

Hmm良い点。私はあなたのデザインが良いと思います。要約データは、必要なルックアップの量のためにユーザーアカウントに便利です。もう1つの例は、私たちが追跡しているプロフィール訪問です。私はこれらを数えるだけでなく、サブテーブルにそれらを格納する。彼らのプロフィールページでは、ちょうど1つのint値を取得するほうがはるかに迅速です。プロファイルページの – Luc

0

私はこれが非常に効果的だとは思わない。たとえば、post_flagsやcomment_flags、photo_flagsなどのフラグの組み合わせを探す必要があるときに便利です。また、クエリの順序も重要です。

+0

には、ユーザーのすべてのフラグの数を表示する必要があります。つまり、各テーブル(投稿、コメント、フラグ)に対してカウントクエリが必要です。 – Googlebot

+0

はい、どうしてですか!私は司会者が質問を移行できると思います。 – Googlebot

関連する問題