2

ニュース サイトを作成していますが、ユーザーが Facebook からステータスを挿入できるようにしたいと考えています。ユーザーは、ニュースを書きながら、ニュースのどこにでもステータスを配置できます。ニュースを挿入したまま表示したい。

ニュースの内容の一例です

"一部のユーザーがテキストを挿入ステータス他のテキスト他のステータス別のテキスト別のステータス"

その場合、良いデータベース設計とは何かを考えています。ステータスには、それを書いたユーザー、日付、および内容があります。ニュースにはタイトル、説明、日付があります。

私は5つのテーブルを考え出しました。

表NewsHeader 

id  
NewsTitle  
NewsDesc  
NewsDate
User

Table NewsContent - ニュースのステータスまたはテキストからの ID とメッセージのみが含まれます

id  
content

テーブルNewsContentDetails - ステータスの詳細が含まれています

id
ContentUser
ContentDate

Table NewsContentDetailsLink - NewsContentとNewsContentDetailsのジャンクション テーブル

NewsContentId  
NewsContentDetailsId

Table NewsHeaderContent - NewsHeaderとNewsContentのジャンクション テーブル

NewsHeaderId  
NewsContentId

それは良いデータベース設計ですか、それとももっと良い方法がありますか? ニュースを表示するときに、SQL クエリに多くの JOIN を記述する必要があり、遅くなることが懸念されます。

編集: @hrr によって提案された DB 設計

**News:**

ID | タイトル | コンテンツ | ユーザー | 日にち

**Elements:**

ID | コンテンツ | ユーザー | 日付 | ニュース_ID

しかし、要素の一部のフィールドは空になり、これは良い選択肢ではないと思います。

前もって感謝します ：）

4

3 に答える 3

2

複数のヘッダーで同じコンテンツを使用したい場合を除き、NewsHeaderContent は必要ありませんが、それが必要だとは思わないので、2 つのテーブルを使用できます。

表NewsHeader

id  
NewsTitle  
NewsDesc  
NewsDate

テーブルニュースコンテンツ

NewsId
ContentId  
Sequence
content
ContentUser
ContentDate

フィールドを使用しSequenceてコンテンツを並べ替えることができます。

この構造のデータの例:

ニュースヘッダー

id    NewsTitle       NewsDesc               NewsDate
 1    'First News'    'Some Description'     2012-10-07
 2    'Another News'  'Description of News'  2102-12-07

ニュースコンテンツ

NewsId  ContentId   Sequence  content                    ContentUser  ContentDate
     1          1          1  'Some Text'                       NULL      NULL
     2          1          1  'Some user inserted text'         NULL      NULL
     2          2          2  [Status]                         User2  2012-12-07
     2          3          4  [Some other status]              User2  2012-12-07
     2          4          3  'Some other text'                 NULL      NULL
     2          5          5  'another text'                    NULL      NULL
     2          6          6  [Another Status]                 User2  2012-12-07

シーケンスは変更可能で、ContentUser と ContentDate はステータスの場合にのみ使用されるため、これらのフィールドを使用してテキストまたはステータスを識別したり、テキストやステータスなどをType保持できるフィールドを追加したりできTます。Sステータス用。

ここに私の例の SQLFiddle があります: SQLFiddle

于 2012-12-07T14:06:00.547 に答える
0

読み取り操作を非常に高速にしたい場合（ニュースサイトであると想定されていると思います）、おそらく次の設計が適していると思います。


全体的なテーブルデザイン： ここに画像の説明を入力してください

  1. ニュースコンテンツとニュースヘッダーを分離する理由がわかりませんか？したがって、これは1対1のマッピングであると想定しています（そうでない場合でも、ソリューションはあまり変わりません）。だから私は単にニューステーブルを持っているでしょう

    ニュース
    ID| タイトル| 説明| 日付| コンテンツ

  2. 次に、UserStatusテーブルがあります

    UserStatus
    id | ユーザーID| ステータステキスト


ユーザーがあなたが指摘したようなニュースメッセージを作成したい場合[「一部のユーザーが挿入したテキストステータス他のテキスト他のステータス別のテキスト別のステータス」]、ユーザーはニュースやステータスを選択するだけです。文の各断片。

ユーザーが文を作成した後、関連するコンテンツのニュースとステータスを取得し、形成されたメッセージをテーブルに直接保存できるため、読み取り用に最適化されたメッセージテーブルが作成されます。 

Message
id | message | User id | DateTime

欠点は、ステータスまたはニュースIDでフィルタリングしたり、ニュースまたはステータスが変更された場合にメッセージを更新したりできないことです。

ユーザーがニュースまたはステータスのいずれかを変更できるようにする場合、またはニュースIDまたはステータスIDでメッセージをフィルタリングする場合の代替手段は、次のとおりです。

ニュースIDのマッピング、ニュースが参照されているメッセージID、およびステータスID、およびステータスがフラグメントシーケンス番号とともに参照されているメッセージID。だからあなたは持っているでしょう：

News-Message-Mapper
News Id | Message Id | Fragment Sequence


と 

Status-Message-Mapper
Status Id | Message Id | Fragment Sequence


フラグメントシーケンスは、メッセージ全体でステータスまたはメッセージが表示される位置を示します。

これで、ニュースまたはステータスが更新または削除された場合、両方のマッピングテーブルを参照し、それらのメッセージを再生成するか、削除するだけです。

これにより読み取りが最適化されますが、更新は複雑ですが、参照整合性と正規化ルールは維持されます。さらに、ニュースIDまたはステータスIDでメッセージをフィルタリングできます

于 2012-12-13T19:21:33.463 に答える
0

News 用に 1 つのテーブルを使用し、Elements 用に 1 つのテーブルを使用できます。

ニュース：

ID | Title | Content | User | Date

要素:

ID | Content | User | Date | News_ID

すべての要素には独自のニュース ID があります。追加の「ジャンクション」テーブルを作成する必要はありません。

于 2012-11-30T21:46:49.713 に答える