4

かなりの量のデータを格納するデータベース構造を計画しています。項目ごとに 50 の異なる「列」のデータを保存する必要があります。タイムスタンプを追加すると、52 列 (および、このデータをフィルター処理する唯一の方法となる 2 つのインデックス) が得られます。このデータベースには、毎日数千行が追加され (更新されることはありません)、しばらく使用されます。

そのため、私の最初の選択は、すべてを 1 つのテーブルに押し込むことでした。52列が悪いのか何か？あまり考えたことはありませんでした。確かに、挿入コードはいらいらするでしょうが、私がそれらを手で書くつもりはありません。

それをいくつかのテーブルに分割する必要がありますか (その後、結合などを使用しますか?)、またはテーブルがそれほど大きくても問題はありませんか? それが違いを生む場合、私はmysqlを使用しています。

追加: データの使用方法を明確にするために:

  • 並べ替えとフィルター処理は、インデックス付きの列に対してのみ行われます。
  • 現在の計画では、データは「人による消費」に使用されるため、常に行全体にアクセスします (必要に応じて csv などに出力します)。
  • 削除や更新はありません。多くの挿入があり、(あまり頻繁ではありませんが) 選択があります。
  • データベース内の他のデータとの「リンク」（外部キーなど）は一切ありません
  • すべてのデータは同じものに関連しています。それを正規化する「明白な」方法はありません。テーブルに分割すると、並べ替えのカテゴリがデータに入れられ、そのように保存されます。
4

4 に答える 4

4

設計を不幸にするのは、列の数ではありません。それらすべての列が実際に同じテーブルに属しているかどうかです。データの正規化ルールは、データがテーブルのキーと密接に関連していない場合に、データを1つのテーブルに格納した場合の結果について多くのことを述べています。

正規化規則と、それらに従わなかった場合に何が起こるかを学ぶことはあなたにふさわしいです。後で、正規化規則からの意図的な逸脱が良い設計につながる可能性がある場合を学ぶこともあなたにふさわしいかもしれません。しかし、テーブルデザインを正規化することの価値を理解するまで、それを学ぶことはできません。

于 2012-07-23T11:39:38.113 に答える
2

可能であれば、いくつかのテーブルに分割（テーブルを正規化）する必要があると思います。次に、私の提案は、頻繁にアクセスするテーブルへのインデックスを使用することです。インデックスを使用すると、クエリを高速化できます。ただし、欠点は、新しいデータを挿入するプロセスが遅くなることです。

于 2012-07-23T10:02:25.307 に答える
1

テーブルに 52 列あること自体には何の問題もありません。

ただし、これらの列の一部のサブセットのみを頻繁にクエリする場合は、そのような頻繁に使用される列を、余分な列を存在させずに独自のテーブルにまとめて格納すると、パフォーマンスが向上する場合があります。

とはいえ、必要に応じて追加の列にアクセスするためにセカンダリ テーブルに結合すると、パフォーマンスが低下するため (またINSERT、2 つのテーブル間で操作が遅くなります)、トレードオフが発生します。また、複数のテーブルはデータの重複 (少なくとも外部キー) につながるため、全体的により多くのスペースを消費することに注意してください。

2 つのアプローチをベンチマークして、自分のケースでどのような違いが生じるかを確認できます。個人的には、パフォーマンスが他の場所を探すようになるまでは、1 つのテーブルを使用します。

于 2012-07-23T10:09:57.427 に答える
0

巨大なテーブルを持つと、インデックスのない列の検索と並べ替えがより面倒でコストがかかります。

小さくて効率的なテーブルを用意することをお勧めします。

データを複数の 1 対 1 のテーブルに分割するか、キー/値テーブルの使用を検討するかを選択できます。

興味がある場合は、キー値テーブルに関する情報: http://www.devshed.com/c/a/MySQL/Database-Design-Using-KeyValue-Tables/

于 2012-07-23T10:06:22.720 に答える