ORMはデータベースの非正規化を促進しますか？

DoctrineとPropelは両方とも単一および具体的なテーブル継承を利用してオブジェクトの関係をマップします。前者は単一のテーブルにマッピングされたクラスツリー内のすべての可能なフィールドを参照しますが、後者は各クラスを特定のテーブルにマッピングし、継承階層の共通フィールドを複製します。

これによりORM装置が容易になりますが、データベース設計が悪いことを示唆しています。これらの悪い設計パターンは、データベースに適用されますか？

特定のデータベースの設計が悪いかどうかを、アプリケーションが何をしているか、データの形状、パフォーマンスの期待などを知らずに言うことは不可能です。一般に（ある程度）正規化はベストプラクティスと見なされますが、パフォーマンス上の理由でデータベースの領域を非正規化することは非常に一般的です。

オブジェクトからリレーショナルへのマッピングに使用できる多くのアプローチを追加すると、「最適な」データベース構造は特定のオブジェクトモデル、継承レベルなどに依存するため、事態はさらに複雑になります。

すべてのアプローチに適合するサイズを採用することにより、ORM永続性ライブラリはほとんど常に、特定の状況に対して最適でないデータベース構造を生成し、特定の状況に対して悪いプラクティスと見なされる可能性のあるものを使用します。

正規化されたORMを書くことはできますが、値が存在するかどうか、キーを取得したかどうか、およびキーを取得したかどうかを確認するためにさまざまなルックアップテーブルをスキャンする必要があるメインテーブルへのすべての挿入に関して、かなり大きなパフォーマンスへの影響があります関連する挿入を実行しません。

（これを手動で行う場合、有効な値のみを含むドロップダウンを提示したことがわかっているので、これらの一部をショートカットすることができますので、これらのルックアップを行う必要はありません。有効であるためには、ORMはUIを制御しないため、その仮定を立てることができませんでした。）

ただし、覚えておく必要があるのは、データベースのパフォーマンスやデータの整合性を最適化することではなく、開発速度を最適化することです。データの特定の構造が重要な場合は、オブジェクト/ RDBMSマッピングを手作業でコーディングするか、少なくとも利用可能なすべてのライブラリの詳細な評価を行い、ニーズに最も近いライブラリを選択する必要があります（存在する場合）。

基本的には、要件と、適切に構造化されたデータ、データベースのパフォーマンス、開発速度のトレードオフに帰着します。多くのトレードオフと同様に、3つすべてを選択することはできません。

経験則として、開発者のニーズを満たすためにデータをモデル化しないでください（そのためにビューまたはSpを使用できますが、データモデルは使用できません）。

データモデルは、アプリケーションおよびパフォーマンスニーズのビジネスルールに基づいている必要があります。

ORMが非正規化または不適切なデータベース設計を促進することに同意しません。実際、私が見た最悪の設計のデータベースは、ORMなしで実行されました。ランダムフィールドの値に基づいてリレーションを作成するのではなく、行IDに基づいて適切なリレーションを簡単に作成できるようにすることで、データベースの設計が向上します。

おそらく正規化は促進されませんが、テーブル/オブジェクトとリレーションを簡単に作成できるORMは、正規化を促進することもできます。ORMでは、住所を従業員テーブルに追加するのではなく、住所を持つ「場所」テーブルを作成し、従業員を場所にリンクすることは、それほど手間がかかりません。しかし、ORMがなければ、ロケーションを分離するということは、そのロケーションにもアクセスするたびに、結合を行う必要があることを意味します。

だから私の答えは：いいえ、そうは思いません。実際には他の方法も考えられますが、少なくとも経験の浅い人については、優れたORM が優れたデータベース設計を促進します。