0

私のサイトでは、ユーザーがいくつかのアイテムを作成でき、それらのアイテムがItemsテーブルに表示されます。
ユーザーは相互にフォローすることもでき、それらのデータをFollowingsテーブルに保存することもできます。
ここで、ユーザー アクティビティを追跡するテーブルが 1 つ必要になるため、次のテーブルを作成しました。

Users{UserId, Username, FirstName, LastName}
Items{ItemId, Title, CreatedByUserId}
Activity{ActivityId, ActivityTypeId, UserId, ItemId}

ここでは、テーブルから、またはテーブルからItemIdできます。 この設計は良いですか、それともこれを行うためのより良いアプローチがありますか?ItemIdItemsUserIdUsers

編集：テーブル構造を追加しました。ポイントは、ユーザーがアイテムを作成したり、ユーザーのフォローを開始したりするたびに、その Activity テーブルにレコードを追加したくないということです。そのため、ユーザーがサイトで何をしたかを常に追跡できます。

4

2 に答える 2

1

ここで、ItemId は、Items テーブルの ItemId または Users テーブルの UserId にすることができます。

これにより、DBMS が外部キーを適用できなくなります。そのルートをたどる場合は、これらのフィールドをより適切に分離し (それぞれのテーブルに対して外部キーを作成できるように)、CHECK を使用してそれらの 1 つだけが非 NULL であることを確認します。

ここに画像の説明を入力

CHECK (
    (ITEM_ID IS NOT NULL AND FOLLOWED_USER_ID IS NULL)
    OR (ITEM_ID IS NULL AND FOLLOWED_USER_ID IS NOT NULL)
)

PK は、ACTIVITY特定のユーザーの「タイムライン」を簡単に照会できるように作成されており、クラスタリングに適しています。

ACTIVITY.TYPE（正確に何を追跡したいかによって、必要な場合とそうでない場合があります。）

別の方法として、アクティビティの種類ごとに個別のテーブルを用意することもできます。

ここに画像の説明を入力

(また、「フォロー」と「フォロー解除」を区別するTYPEフィールドを追加することもできます。)FOLLOW_ACTIVITY

もう 1 つの方法は、共通の親「クラス」からユーザーとアイテムを継承し、そのクラスにリンクすることです。

ここに画像の説明を入力

この場合、この設計はおそらくやり過ぎですが、後で追跡できる他の多くの種類のオブジェクトを追加する場合に役立ちます。

于 2013-01-05T11:20:51.180 に答える
0 
Items{ItemID,descr,UserIDCreator,date-time}
User{UserID,descr}
Followings{UserIDFollowed,UserIDFollower,date-time}

eserによって作成されたすべてのアイテムが、以下のアイテムで同じようにユーザーコードを使用しない場合は、クロノ選択の日時を追加します

データのカーディナリティに依存するトリガーされたテーブルまたはビューを作成できます

ユーザー間で同じオブジェクトを共有できる場合

Items{ItemID,descr,}
UserItems{UserID,descr,ItemId,date-time}
User{UserID,descr}
Followings{UserIDFollowed,UserIDFollower,date-time}

お役に立てれば幸いです

于 2013-01-04T21:07:11.637 に答える