オンラインフォーラムに関する最初の記事で、追加する高度な機能がいくつかある可能性があると述べました。
- ユーザーに関する正式な詳細 単一の「名前」フィールドの代わりに。ユーザーの名前、名前、ユーザー名またはニックネームが必要になる場合があります。優れたフォーラムでは、ユーザーがプロフィール写真、メールアドレス、役割、ステータス（ユーザーをブロックできるようにするため）、および最後にフォーラムにアクセスしたときなどのその他の情報を取得することもできます。
- ユーザーの作成に関連する追加の制御 新しいユーザーがいつ作成されたかを追跡できるようにしますが、そのユーザーのメールアドレスが確認される前です。
- フォーラムカテゴリ 各カテゴリに主題、複数のモデレーター、およびカテゴリの作成日などの追加情報があるサブカテゴリ。コンテンツに加えて投稿の件名
- モデレートされた投稿 他のユーザーに表示される前に、モデレーターによる承認が必要です。投稿とスレッドのステータスは、公開待ち、公開済み、スパムとして報告、ブロック済み、ブロック解除など、さまざまです。
- そして、ユーザーが投票することを許可したい場合があります および投票 スレッドと投稿。
フォーラムでは、「スレッド」という用語を使用して、スレッドに関連する可能性のあるいくつかの投稿がある会話を指します。
冒頭のコメントをします。私は通常、varcharフィールドの長さを定義するために100や1000などのラウンド数を使用します。これらが必ずしも適切なサイズであることを示唆しているわけではありませんが、長さを未定義（％）のままにするのではなく、これを省略形として使用しています。一方、emailのようなフィールドには非常に特定の長さを使用することがあります およびip_address; 254はRFC定義に従って電子メールアドレスが可能な最大長であり、45はIPv6アドレスが可能な最大長です。
ユーザーの詳細
オンラインフォーラムの構築に関する一連の記事のパート1では、ユーザー情報は非常に限られていました。保存されているユーザーの詳細を強化します。今のところ、モデレートは非常に基本的なものです。ユーザーがモデレーターになるかどうかのどちらかになります。後で、カテゴリとスレッドに関連するより複雑なモデレートルールを作成する可能性があります。
ユーザーのステータスについては、user_status 「EMAIL_NOT_VERIFIED」、「VERIFIED」、「BLOCKED」などのステータスが非常に少ない場合でも、別の状況でそれを再利用できるようにします。
ユーザーの作成
ユーザーのステータスを使用して、ユーザーがアカウントを作成し、指定されたメールアドレスにメールが送信された後、メール内の確認URLをクリックする前に、ステータスが「EMAIL_NOT_VERIFIED」になっているユーザーを認識します。これらの手順の一部がシステム内のさまざまなコンポーネントによって処理され、ユーザーの作成中にすぐに処理されない場合は、さらに注意が必要になり、「EMAIL_VERIFICATION_TO_BE_SENT」や「EMAIL_VERIFICATION_RESENT」などのステータスになる可能性があります。
スレッドと投稿のステータス
モデレートされた投稿は、他のユーザーに表示される前に、モデレーターによって承認される必要があります。投稿とスレッドのステータスは、承認待ち、承認済み、スパムとして報告済み、ブロック済みなど、さまざまです。スレッドと投稿のステータスについては、status テーブル。次に、アプリケーションはステータステーブル内の各値の意味を認識している必要があります（status =“ APPROVED”の場合、スレッドが表示されます）が、thread およびpost テーブル。 「WAITING_FOR_APPROVAL」、「APPROVED」、「REJECTED」、「REPORTED_AS_SPAM」、「BLOCKED」など、いくつかのステータスがあり、将来さらに追加する可能性があります。
つまり、ユーザーが新しいスレッドまたは新しい投稿を作成し、ステータスが「NOT_APPROVED」になります。承認されていないスレッドと投稿は、ほとんどのユーザーに表示されません。ただし、モデレーターは未承認のアイテムを表示して、「承認」または「拒否」を選択できます。ユーザーはスレッドまたは投稿をスパムとしてマークできますが、それはモデレーターによって確認される必要があります。スパムスレッドと投稿はユーザーに表示されません。
これにより、status スレッドと投稿の両方のステータスは同じ意味を持つ必要があるため、これらの両方のテーブル。 status ユーザーのステータスを示すテーブル。それは良いデザインの選択ではないと思います。
フォーマルデザイン
そこで、パート1で作成したERDを拡張します。パート1の記事で作成したテーブルを黄色で、新しく追加したテーブルをオレンジで色付けして、追加がわかりやすくしました。ただし、テーブル内の個々の変更にはマークを付けていません。
次は？
繰り返しになりますが、まだ追加の改善が必要ですが、ここでは非常に単純なオンラインフォーラムを利用して、いくつかの便利な新機能を追加しました。
次のパートでは、次のような他の機能の追加について見ていきます。
- フォーラムカテゴリ 各カテゴリに主題、複数のモデレーター、およびカテゴリの作成日などの追加情報があるサブカテゴリ。 件名 投稿の場合 コンテンツに加えて
- そして、ユーザーがスレッドや投稿に賛成票を投じたり、反対票を投じたりできるようにしたい場合があります。
オンラインフォーラムにはどのような機能が必要ですか？このシリーズの次のパートを準備するときに考慮してほしい機能はありますか？もしそうなら、私に知らせてください。
| «前の部分 | 次のパート» |