1

次の方法で、日付とタイプに基づいて SELECT する必要があるさまざまなメッセージ タイプ (20 としましょう) があります。

すなわち... WHERE date BETWEEN [fromDate] AND [toDate] AND type = [0 - 20 different types]

さまざまな種類のメッセージに共通する列はほとんどありませんが (日付が最も重要です)、すべての種類のコメントを「一度に」日付順にフェッチする必要があります。メッセージには、スレッド化された会話を可能にする自己参照があります。メッセージは常に 1 つのタイプであり、1 つのタイプのみです。

アーカイブには 5,000,000 件のメッセージがあり、会話内のメッセージが 50 を超えることはめったにないため、日付または会話 ID で効率的に選択できる必要があります。したがって、単一の「すべてのメッセージの母」テーブルと1 .. 0-1、メッセージテーブルと関係のある複数の追加テーブルがあります。

messages:   [id, date, parent_id (nullable), ... ]
msgs_type1: [col1, col2, col3, col4, ...]
msgs_type2: [col1, col2, col3, col4, ...]

そして、ここで私の質問 です。通常、これらのタイプのテーブル間の関係をどのように指定しますか? たとえば、次の方法でテーブルを結合することの (欠点) 利点は何ですか。

messages: [id, date, parent_id (null), **msg_type_1 (null), msg_type_2 (null)**, ...]
msgs_type1: [col1, col2, col3, col4]
msgs_type2: [col1, col2, col3, col4]
...

(メッセージで指定されたオプションの関係)

messages: [id, date, **type**, parent_id (null)]
msgs_type1: [**message_id**, col1, col2, col3, col4]
msgs_type2: [**message_id**, col1, col2, col3, col4]
...

(msgs_type テーブルで指定された必須の関係、メッセージで指定されたルックアップ テーブル)

あるハンスでは、メッセージのタイプを指定するために、そのうちの 1 つの列 (のみ) に値が必要な 20 のオプションの列があるのは汚いと感じます。

一方、代わりに「タイプ」列挙列を使用し、それを使用して追加情報を探すテーブルを手動で推測することも間違っているように感じます-そしておそらくほとんどのORMで作業するのに多大な苦痛を引き起こすでしょう.

では、この本はこれらのタイプの構造について何と言っているでしょうか? 200 種類のメッセージがある日はどうでしょうか。

4

1 に答える 1

2

IMHO：「何か」の新しい「タイプ」を追加したためにデータベースを変更しなければならない状況にあるときはいつでも、彼らが言うように、それは間違っています。このタイプの列指向テーブルに慣れているのは、たとえば、レポートが生成される直前に実行された場合のみです。または、プロセスの最後に実行して、独自のクエリを生成する可能性のある技術者以外のユーザーの作業を容易にします。

500万から1000万行の適切にインデックス付けされ、正規化されたテーブル構造でも、問題なく機能するはずです。

于 2012-05-04T18:16:04.363 に答える