1

フォーラムのウェブサイトのデータベースを作成したい...

フォーラムWebサイトのすべてのユーザーは、次のフィールドを持つUSERSという名前のテーブルに格納されます。

user_name
user_ID
(and additional details)

次のフィールドを持つFORUMSという名前の単一のテーブルがあります。

forum_ID
forum_creatorID(which is the ID of one of the users)
forum_topic
replies
views

また、作成されたフォーラムごとに（FORUMSテーブルの行ごとに）、「forum_ID」_repliesという名前の個別のテーブルがあり、そのフォーラムの正確なforum_IDが引用符で置き換えられます...
したがって、フォーラムには、その特定のフォーラムへのすべての返信が保存される別のテーブルがあります...

「forum_ID」_repliesテーブルのフィールドは次のとおりです。

user_ID
user_name
comment
timestamp(for the comment)

私は自分のデザインを明確にしたことを願っています...今、私の疑問は

各「forum_ID」_repliesのフィールドの1つとしてuser_nameを保存しました。ただし、user_nameは、各 "forum_ID" _repliesテーブルに格納する代わりに、user_IDを使用してUSERSテーブルから参照（またはアクセス）できると思います。このようにして、冗長性が減少します。

ただし、user_nameが各テーブルに格納されている場合、user_nameの検索が減り、結果をより速く表示できます。

どちらがより最適ですか？

アクセスを高速化するために名前とIDを保存しますか、それとも重複を避けるためにIDのみを保存しますか？

4

1 に答える 1

2

「最適」、「より良い」などはすべて主観的です。

ほとんどのデータベース設計者は、あなたの提案に関していくつかの問題を抱えています。

データベースの正規化では、データを複製しないことをお勧めします-正当な理由があります。ユーザーがユーザー名を変更するとどうなりますか？ユーザーテーブルを更新する必要がありますが、ユーザー名が含まれるすべての「forum_id」_repliesテーブルも検索します。それを台無しにすると、突然、かなり明白なバグが発生します。人々は「bob」に返信していると思いますが、実際には「jane」に返信しています。

パフォーマンスの観点から、難解なパフォーマンス要求がない限り（たとえば、Facebookを実行している場合）、ユーザーテーブルへの参加は測定可能な影響を与えません。つまり、主キー列に参加します。これがデータベースです。本当に、本当に得意です。

最後に、パフォーマンス/スケーラビリティのニーズが非常に大きい場合を除いて、フォーラムごとに個別のテーブルを作成することはあまりお勧めできません（Facebookの場合を読んでください）。データベースの保守、クエリの作成、アプリのデータベースへの接続などがさらに複雑になります。重要です。通常、複数のフォーラムを1つのテーブルに保存することによるパフォーマンスのオーバーヘッドはありません。

「より良い」はあなたの基準に依存します。（コメントに書いているように）スケーラビリティと膨大な数の投稿のサポートについて懸念がある場合は、スケーラビリティレベルをテストおよび測定する方法を構築することから始めることをお勧めします。テストと測定ができたら、さまざまなソリューションをテストして、それらが重大な影響を与えるかどうかを知ることができます。多くの場合、これは直感に反する結果を示します。パフォーマンスの最適化は、他の基準を犠牲にして行われることがよくあります。たとえば、設計はエラーが発生しやすく（情報が繰り返されると不一致が生じる可能性があります）、コーディングに費用がかかります（フォーラムごとに異なるテーブルに結合するロジックを記述します）。スケーラビリティに重要なメリットがあり、このメリットがビジネス要件を満たしていることを証明できない場合は、時間とお金を無駄にしている可能性があります。

DBMonsterなどのツールを使用してデータベースにテストデータを入力し、JMeterを使用して多数の同時データベースクエリを実行できます。これらのツールを使用して両方のソリューションを試し、ソリューションが実際に高速かどうかを確認してください。

于 2013-02-12T17:31:14.900 に答える