0

私は現在、大規模なアプリケーション用のフォーラム コンポーネントを構築しており、データベース スキーマの特定の部分に対するさまざまなアプローチを検討しています。特に、トピックと投稿を 1 つのテーブルで表すことを検討しています。トピックと投稿は実質的に同じと考えていますが、これにより将来的に柔軟性が失われる可能性があるため、少し不安を感じています.

特定のフォーラムのトピックがクエリされると、タイトルと最初の投稿、およびユーザー情報の一部 (基本的には名前とアバター) が表示されます。このアプリケーションには、ビューと返信を除くトピックと投稿の両方で使用されるさまざまな属性があります。おそらく、title、および forum_id(forum_id は、トピック リレーションの forum_id 属性を変更するのではなく、トピックが別のフォーラムに変更された場合、潜在的に数百のレコードが影響を受ける必要があることを意味するためです)。

テーブルは、私が以下に持っているもののように見えます:

TOPIC            POST           
topic_id         poster_id   
forum_id         topic_id 
poster_id        content 
title            upvote
views            dnvote
replies          closed
post_id          deleted
                 last_edited
                 last_editor
                 parent_id
                 content
                 post_id

テーブルの継承を使用してこのように行うと、トピックで投稿を生成するには、TOPIC、POST、USER、および TOPIC_TYPE を介した 4 つのテーブルの結合が必要になります。

一方、単一テーブル アプローチを採用することに決めた場合、topic_type が通常の投稿の場合、views、replys、title、および forum_id 属性を null のままにしておく必要がありますか? (topic_type は、表示されるトピックのタイプに適したアイコンを参照し、統計などに使用されます。)

4

3 に答える 3

1

リレーショナル テクノロジの使用に確実に取り組んでいる場合 (Mongo などの NoSQL データベースも検討します)、提案したように 2 つのテーブルに分けます。

ここでのケースは、リレーショナル マスター/ディテール デザインまたは全体パーツの基本であり、2 つのテーブルが適切だと思います。

于 2012-12-09T04:33:38.577 に答える
0

このシナリオでは、単純な正規化が推奨されると思います。さまざまな種類のレポートを生成することも役立ちます。単一のテーブルを使用することもできますが、この場合はテーブルを設計したので、同じ値を複数回入力しないように管理しやすい2つのテーブルを使用する場合。

于 2012-12-09T04:57:01.687 に答える
0

「トピック」と「トピックスターター」を区別することは価値があるかもしれません。「トピック スターター」とは、返信ではないコメントです。すべてのトピックには、トピック テーブルの外部キーによって参照できるトピック スターターが 1 つだけあります。

それ以外は、あなたの分析とデザインの両方に同意します。

于 2012-12-09T06:26:24.987 に答える