実世界での正規化
データベースの正規化は、アプリケーション開発の神聖な牛の1つです。 あなたが読んだか読んだことがあるすべての学部のプログラミングコースは、 データベースを正規化することの重要性を説くでしょう。
その真実主義に挑戦する時です。 場合によってはデータベースを非正規化することもできます。
あなたはいつ正規化すべきですか？
データベースの正規化は、データの整合性を保護します。 多くの場合、優れたアイデアです。正規化を考慮して、データベース設計の作業を開始する必要があります。 あなたがデータベースを正規化できるなら、それを手に入れてください！ 実際には、このサイトでデータベースを正規化する方法に関する実践的な助言があります：
要するに、そうしないと正当な理由がない限り、データベースを正規化する必要があります。 ノーマライズは、通常、健全なデザインの練習です。 冗長な情報を減らし、パフォーマンスを最適化し、同じデータをデータベースの別の場所に格納することによるデータの完全性の問題を軽減します。
いくつかの良い理由が標準化していない
つまり、データベースを正規化しないとよい理由がいくつかあります。 いくつかを見てみましょう：
- 結合は高価です。 データベースを正規化すると、多くのテーブルが作成されることがよくあります。 実際には、5つまたは10つのテーブルにまたがる単純なクエリであると思われるものを簡単に解決できます。 これまでに5つのテーブルに参加しようとしたことがあるなら、それは原則的に機能することがわかっていますが、実際には辛抱強く遅くなっています。 大規模なテーブルに対して複数の結合クエリを使用するWebアプリケーションを構築する場合は、「このデータベースのみが正規化されていないと！」と思うかもしれません。あなたの頭にその考えが聞こえたら、非正規化を検討する。 実際にデータの整合性を損なうことなく、そのクエリで使用されているすべてのデータを単一のテーブルに張り付けることができれば、それを実行してください！ 反逆し、あなたのデータベースを非正規化してください。 あなたは振り返ることはありません！
- 標準化された設計は難しい 。 複雑なデータベーススキーマを使用している場合は、正規化の複雑さを超えてテーブルに頭を抱えるようになるでしょう。 簡単な経験則として、1日中、4番目の正規形に移動する方法を理解しようとすると、標準化があまりにも進んでいる可能性があります。 それが本当に続ける価値があるかどうか尋ねてください。
- クイックと汚れはすばやく汚れているはずです。 プロトタイプを開発しているだけの場合は、すぐにどんなことをしても構いません。 本当に。 大丈夫です。 エレガントな設計よりも迅速なアプリケーション開発が重要な場合があります。 試作段階を踏み出す準備が整ったら、設計を慎重に見直してください。 クイックで汚れたデータベース設計のために支払う価格は、生産のためにビルドするときにはそれを捨て、最初からやり直す必要があるかもしれないということです。
- NoSQLデータベースを使用している場合 、従来の正規化は望ましくありません。 代わりに、はるかに寛容なBASEモデルを使用してデータベースを設計してください。 これは、電子メール、画像、ビデオなどの非構造化データを格納する場合に便利です。
注意の言葉
データベースの正規化は一般的には良い考えです。 正規化の原則に従うことが妥当と思われる場合は、そうすることをお勧めします。 しかし、すべての指標が正規化を実装するにはあまりにも複雑であると指摘している場合は、データを保護しながら仕事を達成する方法を検討してください。
最後に、正規化のルールから逸脱することを選択した場合は、データベースの整合性をどのように強制するかについてさらに注意してください。 冗長な情報を保存する場合は、トリガーやその他のコントロールを配置して、情報の一貫性を保ちます。