0

フォーラムを構築していますが、すべての主要な投稿を保存する 1 つのテーブルを作成し、すべての回答を別のテーブルに保存する必要があるかどうか疑問に思っています。

私は常にすべてを 1 つのテーブルに保存しており、すべての投稿をカウントし、ユーザーがすべての投稿にコメントできるようにしています (コメントは別のテーブルにあります)。

私は何をすべきか？長所と短所？グーグルで検索しようとしましたが、何も見つかりませんでした。

ご協力いただきありがとうございます！

4

3 に答える 3

0

私は通常、ルールに従いますevery type of dataset gets a own table。このようにして、関係を明確に定義できます

次のようなタイプがあります

  • userTypes (例: guest、user、mod、admin)
  • ユーザー (1 つの userType_id を持つ)
  • 投稿 (1 つの user_id を持つ)
  • 回答 (post_id が 1 つある)
  • コメント (post_id が 1 つ、answer_id が 1 つ)

コメントは投稿と回答の両方に追加できるため、2 つのブリッジ テーブルを追加してこの関係を定義できます。

  • comment_to_answer (comment_id が 1 つ、answer_id が 1 つ)
  • comment_to_question (comment_id が 1 つ、question_id が 1 つ)

投稿と回答の両方を 1 つのテーブルに保存する場合、投稿テーブルは投稿と回答の 1 対多の関係を定義するために自分自身を参照する必要があり、クエリがより複雑になります。

カスケードできるようにしたい場合は、投稿に回答を含めることができ、回答に回答を含めることができます.1つの投稿テーブルと、投稿のIDを指すparent_idを使用するとよいでしょう

お役に立てれば。

于 2013-01-01T11:16:46.687 に答える
0

これは、ユーザーのニーズと意図に依存するため、非常に主観的なものです。説明させてください...

フォーラムは、通常、2 つの形式のいずれかを取ります。それらは、メインの投稿の形をしており、その後にコメントが続く場合があります。したがって、メインの投稿は論理的に 1 つのテーブルに、コメントは別のテーブルに配置されます。Facebook や Stack Exchange サイトがその例です。

それ以外の場合、コンテンツはコメントのリストの形式をとる場合があります。より伝統的なフォーラムはこの形式をとっています。純粋な日付順ではなく、階層が必要な場合は、単一テーブル アプローチの方が理にかなっています。

parentどちらの場合も、 andchild列を作成することで階層を処理できます。

私の個人的な好みは、メインの投稿にコメントに不要な追加データの順序が含まれていない限り、1 つのテーブルを使用することです。NULLこれは単なる効率の問題ですが、無駄にスペースを占有する s を含む何千または何百万もの行は絶対に必要ありません。投稿とコメントを区別するために、個別の ID やフラグ列など、任意の数の論理スキームを使用できます。

最終的に、このようなアーキテクチャの状況は、問題のプロジェクトによって異なります。どちらのアプローチにも長所と短所があります。複数のテーブルを使用すると、後で複雑さが追加された場合にプロジェクトを「将来的に保証」する方法がもう少し提供されます。

于 2013-01-01T11:11:46.477 に答える
-1

1 つの投稿に複数の回答が含まれる可能性があるため、別の表を使用します。

プロ：

  • 冗長性の少ない情報
  • 回答は、投稿とは独立して更新/削除できます
  • 質問/回答の簡単なカウント

コン

  • 非（まあ、特定のクエリのためにテーブルを結合する必要があるかもしれませんが、それは実際にはカウントされません）

別のテーブルに既にコメントがあるのと同じ理由...

于 2013-01-01T11:00:36.560 に答える