同じデータ、それ

Question

2つの以下の表の両方が同じデータを保持することができます保存するには、2つの異なる方法 - 通年、毎月

table1 (one row = one month) 
------ 
id 
month 
year 
info 

table2 (one row = one year) 
------ 
id 
year 
jan_info 
feb_info 
mar_info 
apr_info 
may_info 
jun_info 
jul_info 
aug_info 
sep_info 
oct_info 
nov_info 
dec_info 

表に関するいくつかの任意の情報を含みますA

• 月が数値なので、よりわかりやすいようですが、
• 1年間に10倍以上の行があります。また
• 行が小さい（少ない列）データの通年の

表B

• 10倍以下の行ですが、
• シングル行は、おそらくより
• はるかに大きいです1ヶ月に任意の情報を追加するのが難しい

現実世界のテスト風景私がセットアップしたのは、テーブル1にはテーブル10に12,000行あり、テーブル2には150がありました。私が片方の方法をとると後で気になる警告を見落としてしまうのではないかと心配しています。私はディスクの使用量や、どのようなクエリが高速かもしれないと考えています。 MySQLは何を好みますか？ 「正しい」方法はありますか？それとも「より良い」方法がありますか？

ありがとうございました！

Answer 1

保存方法を考えないで、使い方を考えてください。また、今後どのように変化するかも考えています。ストレージ構造は使用を反映する必要があります。

第1のオプションは第2のオプションでより正規化されているので、私はそれを好む傾向があります。たとえば毎月突然それについて保存された2番目の情報が必要な場合など、簡単に変更できるという利点があります。通常、この種の構造はより簡単に作成できますが、必ずしもそうではありません。データがどこから来ているのか考えてみてください。

このデータのみをレポートに使用していて、数か月間にデータを集計する必要がない場合は、2番目のオプションを使用します。

本当にデータが何であるか、どこから来たのかによって異なります。しかし、一般的には、最初の選択肢が優れています。

Answer 2

データの10年間の12000行？まあまあ、12000行はまともなDBMSのないものです。

どのようにデータベースを使用していますか？最適化について本当に心配する必要はありますか？

月に固有のデータを格納する必要がある場合は、毎月の行を絶対に保存する必要があります。これは、毎月の列を持つものと比べて、よりクリーンなアプローチです。

Answer 3

どのようにデータを使用していますか？あなたがしばしば月単位でデータを分割するレポートを作成している場合、2番目の方が簡単です（おそらく高速ですが、自分でテストする必要があります）。それは標準化されていませんが正直なところ、私たちが今年の新しい月を最後に追加したのはいつですか？

Answer 4

「私がセットアップした現実世界のテスト風景では、table2に150,000のデータがあり、table2には150,000のデータがありました。

どのようにですか？それが事実であるためには、1年で80ヶ月が必要です。

Answer 5

これは最適化の問題であるため、最適化の答えが適用されます。

あなたのデータはどうしますか？

表Aは、この種のデータを格納する通常の形式です。

表Bは便利な場合がありますが、わかりやすい例を見つけることが必要です。

だから、Aと一緒に行くか、データで何をしたいかについての詳細を教えてください。

ディスクスペースに関する注意：ディスクスペースの合計は、非常に巨大なテーブルを除いては問題ありません。選択肢ごとにすべてのディスクスペースが必要な場合は、ほとんどの場合、テーブルAデザインの方が少なくてすみます。

計算上の注意：12000を12で割って結果として150を得ると、何かが間違っています。

Answer 6

一般的には、より一般的な解決策として1か月あたり1レコードと言います。

「info」が論理的に常に1つのフィールドであるかどうか、という重要な問題が1つあります。実際に月に数個のデータがある場合や、将来的にそうなる可能性がある場合は、それらをすべて1つのテーブルに入れることは大きな苦痛になります。

もう1つの質問は、このデータで行うことです。あなたは「情報」が何であるかを言わないので、議論の目的のために、それが「月の売上」であると仮定しよう。 "何ヶ月で売上高が1,000,000ドルを超えたのですか？" ？ 1ヶ月あたり1レコードで、これは簡単なクエリです。「年を選択します。売上高はmonth_sales> 1000000」です。今年の年表でそれをやってみてください。 jan_sales> 1000000組合選択年、year_sales> 1000000組合選択年、 'mar' year_sales> mar_sales> 1000000 union ...などなど、year_salesのどこから 'Feb'を選択するかを指定します。 jb_sales> 1000000 then 'Jan = yes' else 'Jan = no'、feb_sales> 1000000、 'Feb = yes' else 'Feb = no' ...残りの月間。 。year_salesからjan_sales> 1000000またはfeb_sales> 1000000またはmar_sales> 1000000 ... "Yuck。

多くの小さなレコードを持つことは、少ないレコードだが大きなレコードを持つよりもはるかにリソースの負担ではありません。はい。レコードのオーバーヘッドにより、必要なディスク領域の合計が確実に増えることになります。索引が大きくなるため、索引検索はいくらか遅くなります。しかし、その違いは軽微である可能性があります。率直に言えば、この種のことは予測が困難なデータベースパフォーマンスには非常に多くの要因があります。

しかし、私はちょうど非常に似た問題に直面し、逆に進んでいたことを認めなければなりません。毎日、「今日は働いていますか？私は1日に1つのレコードで別のテーブルを作成するかどうかを検討しましたが、7つのフィールドを1つのレコードにまとめることになりました。私の考えは、デザインに根本的な変更を加えることなく、毎日のための追加データが存在することは決してないだろうということです。ただ1日しか見たくない理由はありません。日はスケジュールを計算し、支払期日を割り当てるために使用されるので、このアプリケーションの文脈では、「火曜日に働いているすべての人に私に教えてください」と言いたいことは想像もできません。しかし、私は簡単に、異なるアプリケーションで同じデータを正確に使用していると想像することができます。