2

質問回答サイトをやっています。苦情調整プロセスのテーブルをいくつか設計する必要があります。このプロセスでは、すべてのユーザーが質問に対して苦情を申し立てることができ、モデレーターは、質問に関する特定の種類の苦情が一定数に達すると、苦情を受け入れることができます。

詳細に：

ユーザーが質問します。次に、この質問を読んだ別のユーザーが、苦情の種類にフラグを立てたいと考えています。

このユーザーが何らかの苦情を含む質問にフラグを立てると、その質問は保存されます。フラグには type プロパティ (ComplaintA、ComplaintB、ModeratorAttention、..) があります。

モデレーターは、すべての質問に関するフラグを表示できます。質問に関する ComplaintA タイプのフラグの数が一定数 (10 のような定数) に達すると、モデレーターはこれらのフラグを受け入れます。

次に、同じタイプのこれらのフラグがメッセージとともに保存されます。このメッセージは、フラグ作成者 (ProcessType が ComplaintsAccepted) で問題が発生したときに表示されます。

次に、質問をしたユーザーが、質問を修正した後、モデレーターの注意にメッセージ付きのフラグを送信できます。モデレーターは、修正が満足のいくものである場合 (ProcessType が ResolutionAccepted)、苦情の解決を受け入れることができます。

私のドラフトデザインの詳細：

Users (Table of Sql Membership Provider)
-----
- UserId
- Password
- Email
-...

Questions
---------
- QuestionId
- ...

Flags
----------
- FlagId
- QuestionId
- FlaggerId --> Flagger is a user
- FlagType --> ComplaintA, ComplaintB, ModeratorAttention
- FlagMessage

ModeratorProcesses
------------------
- ProcessId
- ProcessMessage
- QuestionId
- FlagType
- ProcessType   --> ComplaintAccepted / ResolutionAccepted / DeleteAccepted
- ModeratorId   --> Moderator is a user
- DateOfProcess

テーブル関係: ModeratorProcesses - 1:m - フラグ - n:1 - 質問

これは、このプロセスにとって適切なデータベース設計ですか?

4

1 に答える 1

1

これは、このプロセスに適したデータベース設計ですか?

データベースの設計は、要件に一致しているように見えます。

エンティティ名は通常、複数形ではなく単数形です。ユーザー、質問、フラグ、モデレーター プロセス。

Flag エンティティでは、列 FlaggerId を呼び出すのではなく、列 UserId を呼び出します。そうすれば、外部キーの関係は明らかです。ModeratorProcess エンティティで、ModeratorId を UserId に同じように変更します。FlagType と ProcessType のコメントは、列を説明しているので問題ありません。

ModeratorProcess エンティティの DateOfProcess ではなく、ProcessTimestamp と呼びます。それは日付/時刻フィールドである必要があります。おそらく、Flag テーブルにタイムスタンプ フィールドが必要になるでしょう。

于 2013-05-25T12:13:23.967 に答える