sql - データベース設計 - テーブルをいつ分割するか?

Question

別のテーブルを作成すると、より多くの作業が発生することがありますが、とにかく分割する必要がありますか?

例：私のプロジェクトでは、顧客のテーブルがあり、各顧客は各製品に対して独自の特別価格を持っています（製品は5つしかなく、将来的にそれ以上の製品は計画されていません）。各顧客には固有の曜日もあります。会社は彼に製品を届けます。

顧客の日数/価格の変更、またはすべての顧客の日数と価格の表示などの多くの操作は、日数と製品価格が個別のテーブルではなく顧客テーブルの列である場合にはるかに簡単になるため、大規模な顧客を 1 つだけ作成することは反論されますか?そのような場合のテーブルは？欠点は何ですか？

更新:彼らは、1年ほど後に製品を追加する可能性があることを私に知らせました. このような場合、製品の価格に関係がない (各顧客には独自の特別価格がある) 場合、列を Customers テーブルに追加するよりも Products テーブルに行を追加する方がよい理由はまだわかりません。私が考えることができる唯一の利点は、製品が 5 つしかない顧客が 20 個の null 可能な製品を「運ぶ」必要がないことです (サーバーのスペースを節約します)。私はあまり経験がないので、明らかなことを見逃しているのでしょうか？

Answer 1

明らかに、常に正規化する必要があると言うだけでは実用的ではありません。アドバイスは常に真実ではありません。

5つの「アイテム」で長い間十分であると確信を持って言えれば、作業を節約できるのであれば、それらを列として保存するだけでまったく問題ないと思います。

予測が失敗し、6 番目の項目を保存する必要がある場合は、新しい列を追加できます。列の数が非常に高い確率で手に負えなくなっていない限り、これは問題になりません。

多くのプログラマーが将来を予測する能力は非常に限られていることが判明しているため、そのような戦術には注意してください。

最終的に重要なことは 1 つだけです。それは、要求されたソリューションを最小のコストで提供することです。コードの純粋さは目標ではありません。

Answer 2

正規化は、データの整合性 (一貫性) に関するものであり、それ以外のことではありません。難しい、簡単、速い、遅い、効率的、その他のあいまいな属性についてではありません。現在の設計では、ほぼ確実にデータの異常が許容されます。今すぐでなくても、価格の変更、請求書、注文などを追跡しようとすると、行き止まりになります。