2

私はDB設計に不慣れで、これで正しい軌道に乗っていることを確認したかったので、ちょっとした「ベストプラクティス」の質問

ユーザー (1 人)、グループ (多くのユーザー)、会社 (多くのグループ) の 3 つのユーザー タイプがあり、それぞれにメッセージを投稿できる独自のログインがあります。だから例えば。企業がメッセージを投稿すると、リンクされたすべてのユーザーのニュース フィードに表示されます。

これを達成するために、メッセージの内容を格納するテーブル「メッセージ」と、ユーザータイプをリンクするための外部キーがあります

これを達成するために、次のスキーマ（PostgreSQL）を使用するつもりでした...

create table notifications(
    notification_id serial primary key,
    user_id integer references users,
    group_id integer references groups,
    company_id integer references companies,
    date_created timestamp not null default now(),
    title_id text not null,
    message_id text not null,
    icon text not null default 'logo'
);
comment on table notifications is 'Messages to be displayed on a users home feed';

これにより、ユーザーのニュース フィードに関連するメッセージを抽出するクエリを作成できます (たとえば、user_id、group_id、または company_id の 1 つのフィールドのみが値を持ちます)。

しかし、これは最善の方法ですか？Null可能な外部キーを持つことは悪い考えだと確信しています.一種の列挙キーを使用したより良い解決策があるのではないかと考えていましたか? (これもあるの!?)

ありがとう

4

1 に答える 1

4

高度に正規化された1つのオプションは、テーブルをより似たものにすることです

create table notifications( 
    notification_id serial primary key, 
    date_created timestamp not null default now(), 
    title_id text not null, 
    message_id text not null, 
    icon text not null default 'logo' 
); 

create table usernotifications
(
    notification_id integer references notifications,
    user_id integer references users
);

create table groupnotifications
(
    notification_id integer references notifications,
    group_id integer references groups
);

create table companynotifications
(
    notification_id integer references notifications,
    company_id integer references companies
);

エントリは、特定の通知に関連する (ユーザー/会社/グループ) 通知テーブルにのみ存在します。

(外部キーがオプションであることを示す状況では、null 可能な外部キーに問題はないと思いますが、同様のタイプの複数の外部キーは、非正規化された設計の印象を与えます)

于 2012-08-21T09:27:09.410 に答える