[解決済み] テーブルを増やすか、カラムを増やすか、どちらが良いデータベース設計か？

質問

以前の同僚が、より少ないテーブルでより多くのカラムを持つデータベースは、より少ないテーブルでより多くのカラムを持つデータベースよりも優れていると主張していました。 たとえば、名前、住所、都市、州、郵便番号などの列を持つ顧客テーブルではなく、名前テーブル、住所テーブル、都市テーブルなどを持つことになります。

彼は、この設計がより効率的で柔軟であると主張しました。 おそらく、より柔軟なのでしょうが、私にはその効率についてコメントする資格はありません。 たとえより効率的であったとしても、追加された複雑さによって、それらの利益が打ち消されるかもしれないと思います。

では、より少ない列でより多くのテーブルを作成することは、より多くの列でより少ないテーブルを作成することよりも重要な利点があるのでしょうか？

どのように解決するのですか？

私はデータベースを設計するときに従ういくつかのかなり単純な経験則を持っていますが、これはこのような決定をするのに役立つと思います...。

1. 正規化を支持する。非正規化は、必要なすべてのトレードオフを伴う最適化の一形態であり、そのようなものとして、次のような方法でアプローチされるべきです。 YAGNI の態度で臨むべきです。
2. データベースを参照するクライアントコードがスキーマから十分に切り離されていることを確認し、それを再調整することでクライアントの大規模な再設計が必要ないようにします。
3. パフォーマンスやクエリの複雑さに明らかな利点をもたらす場合は、非正規化を恐れないでください。
4. スキーマのコアを非正規化するのではなく、ビューや下流テーブルを使用して非正規化を実装します。 データ量と使用シナリオが許す限り、非正規化を行う。 .

これらのルールの通常の結果は、最初の設計では、冗長性を排除することに重点を置いて、列よりもテーブルを優先することです。 プロジェクトが進行し、非正規化ポイントが特定されると、全体的な構造は、他の価値ある利点と引き換えに、限られた冗長性と列の増殖で妥協するバランスに向かって進化するでしょう。