0

明確にするために、私はここでフォーラム全体を設計する人を探していません。むしろ、いくつかのテーブルを関連付ける方法、およびこれらのテーブルが最初に存在する必要があるかどうかを判断するための助けが必要です。

フォーラムの基本

トピック

topic_id //一意のトピックID、AI、PK
topic_name//トピックの名前
...など
  • トピック
  • これらのトピックの投稿（これがここにあるものです、投稿
  • 投稿への返信。これが以下の回答です（あなたの回答）

ユーザー

user_id //ユーザーの一意のID、PK、AI
user_name
user_pass
user_email
user_date

投稿

post_id //投稿の一意のID-PK、AI
post_content
...など

投稿を好き/嫌いにする機能も含めたいので、次のようなテーブルを作成しましpost_rankingた

id//自動インクリメントID    
post_id//外部キー。post.post_idを参照します。
user_id//外部キー。user.user_idを参照します
vote_up //投稿が投票されたかどうか（0は下、1は上）
rank_date//ランキングが発生した日付

私が遭遇したばかりの問題は、このテーブルに返信を組み込む方法がわからないことです。私がこれまで考えてきた唯一のオプションは、という2番目のテーブルを作成することreply_rankingですが、これはやや整理されていないのではないでしょうか。

だから、私の質問：

ランキング（post_ranking、reply_ranking）用に2つの別々のテーブルを作成する必要がありますか、それとも、そもそもこの問題を回避するために上記のテーブルを配置する別の方法がありますか？

4

3 に答える 3

0

私は通常このように思います：

1人のユーザーには多くの投稿があります（つまり、usersテーブルとテーブルが必要でありposts、すべての投稿には、誰がそれを所有しているかを示すuser_idがあります。

一部の関係では（たとえば、Aに多くのBがあり、Bに多くのAがあることに気付いた場合、それがn対nの関係になります）、3番目のテーブルが必要になります。これは、データベースで応答エンティティを何に変換する必要があるかについてのコメントで示唆していることかもしれません。

気軽にエラーを犯してください...あなたが始めたのとまったく同じモデルになってしまうことはほとんどありません...私たちがやるまで必要かどうかわからないことがたくさんあります。

于 2012-10-13T10:01:45.420 に答える
0

もう1つできることは、単一のランキングテーブルを作成することです。このテーブルには、賛成/反対の投票が投稿用かランキング用かを示すフィールドがあります。投稿IDまたは返信IDの代わりに、一意ではない汎用の「item_id」を使用する必要がありますが、これが重要な場合は、1つのテーブルを取得します。

編集：同じ投稿に複数の票がある可能性があるため、外部キーフィールドはとにかく一意ではないことに気づきました。重要なのは投稿IDと返信IDを区別できないことです。

これにより、テーブルのクエリを処理するのが難しくなります。私の推奨は、現在の計画に沿って2つのテーブルを作成することです。これは、データを整理するための最も意味的な方法です。

于 2012-10-13T10:13:03.297 に答える
0

あなたの投稿はあまり明確ではありません。あなたが中に持っているトピックがそのトピックに投稿され、そのトピックに返信するかどうかはわかりません。

この場合、これは良い方法ではないと思います。トピックデータから投稿を分離する必要があります。説明させてください。

フォーラムは以下によって形成されます。

//                MAIN PAGE, showing avaible forums
//                    |
//              SPECIFIC FORUM, that show the threads (or topics) inside
//                    |
//                  POSTS that show part of the post related to that thread.
//
//       USER_CP -------------- ADMIN_CP

少なくとも4つのテーブルが必要です（私はadmin_cpを考慮していません）。これらは：

//  TOPICS:
//  +---------------+---------+-------------+----------+----------+----------------+
//  | ID, p.k. a.i. |  TITLE  |  SUB_TITLE  |  AUTHOR  |  CLOSED  |  PARENT FORUM  |
//  +---------------+---------+-------------+----------+----------+----------------+
//
//  These are very few basic field for the table. No reference about the posts here.
//
//
//  FORUMS:
//  +---------------+---------+-------------+--------------+
//  | ID, p.k. a.i. |  TITLE  |  SUB_TITLE  |  VISIBILITY  |
//  +---------------+---------+-------------+--------------+
//
//  Almost clear, visibility is a value to determine if the forum is private (such are
//  forums like: "Moderator rooms" or "Admin stuff"), protected (i.e. for non registered
//  users, or if the forum is public.
//
//
//  POSTS:
//  +---------------+----------+-------+-----------+--------+---------+-------+- - -
//  | ID, p.k. a.i. | TOPIC_ID | TITLE | SUB_TITLE | AUTHOR | MESSAGE | VOTES | ...
//  +---------------+----------+-------+-----------+--------+---------+-------+- - - 
//  
//  In Votes you have a integer number (positive o negative, no matter) with the total
//  of the votes for this post (not useful if you fully use the table like).
//
//  REPLIES
//  +---------------+----------+---------+--------+---------+
//  | ID, p.k. a.i. | TOPIC_ID | POST_ID | AUTHOR | MESSAGE |
//  +---------------+----------+---------+--------+---------+
//
//
//  USERS
//  +---------------+------+------+------------+------+---------+- - - - -
//  | ID, p.k. a.i. | NICK | PASS | PRIVILEGES | NAME | SURNAME | ETC..
//  +---------------+------+------+------------+------+---------+- - - - -
//
//  Privileges determinate if a user is admin, mod, super_mod or simple user
//
//
//  LIKES
//  +---------------+---------+---------+----------+----------+---------+------+
//  | ID, p.k. a.i. | USER_ID | POST_ID | TOPIC_ID | REPLY_ID | UP_DOWN | DATE |
//  +---------------+---------+---------+----------+----------+---------+------+

これは、私の意見では、使用する必要のある構造です。

ホームページ、すべてのフォーラムを表示します。

  • ユーザーの権限を読み取る
  • テーブルからフォーラムのデータを読むWHERE visibility >= user_privileges
  • 適切なリンクを各フォーラムに浸透させます。

フォーラムページ、すべてのトピック（およびモデレーター）を表示します。

  • 表からトピックを読むWHERE parent_forum = forum_id
  • このフォーラムのモデレーターを読む
  • 適切なリンクでトピックを浸透させる
  • ページの下部にモデレーターを表示します。

トピックページ、すべてのメッセージを表示します。

  • テーブルからtopiデータを読み取ります。
  • トピックは最初のメッセージでもあります！
  • テーブルから投稿を読むWHERE topic_id = current_topic_id
  • テーブル「LIKES」から読み取った投稿ごとにWHERE post_id = selected_post
  • すべての投票を合計する
  • 適切なページと適切な投票で投稿を浸透させます。

ユーザーページ：

  • すべてのデータを読み、WHERE id = user_id_that_want
  • 「いいね」から読むWHERE user_id = actual_user
  • ユーザーが送信したすべてのいいね/嫌いがあります。あなたがやりたいことをしなさい。
  • 浸透する

このテーブル構造を使用すると、StackOverflowと同様の方法で投票を検討できます。つまり、投票者の場合、賛成票は0ですが、反対票は-1です。投稿ごとに、post_idを使用するだけで同様のテーブルから読み取ることができるため、投稿の投票数（上下）がわかります。これにより、投稿作成者に+10票、投稿に-5票に投票することもできます。作成者。

好きな追加のテーブルがある場合のみ。

あなたが持つことができます：

  • トピックに投票する
  • 投稿に投票する
  • 返信に投票する
  • トピックの合計投票数（返信+投稿+トピック）。

トピックを挿入すると、次のものが追加されます。

user_id
topic_id = topic id
post_id = -1 (this is not a post, is the topic!)
repl

y_id = -1（上記のとおり）

投稿を挿入するとき：

user_id
topic_id = current topic
post_id = post_id
reply_id = -1 (this is not a a reply)

返信を挿入するとき

user_id
topic_id = current topic
post_id = current post
reply_id = the reply id.

これにはidの問題はありません。3つが分かれているからです。

特定のトピックと特定の投稿のすべての回答を求める場合は、次を追加します。

WHERE topic_id = current, post_id = current

トピックの返信が必要な場合は、post_id=-1と入力してください。

等々。IDに問題はありません！

私はほとんどすべてを説明したと思います。ご不明な点がございましたら、お問い合わせください。編集：あちこちで何か

于 2012-10-13T10:31:34.787 に答える