私は現在、変更の摩擦を最小限に抑える、保守性の高いシステムのアプリケーション設計のベストプラクティスを（かなり高いレベルで）調査しています。「データ層」とは、データベース設計、オブジェクトリレーションマッパー（ORM）、および一般的なデータアクセステクノロジを意味します。
あなたの経験から、データ層の開発に関してよくある間違いと悪い習慣は何であると思いますか、また、データ層を開発者にとってより良い場所にするためにどのような対策を講じ/実施しましたか/または推奨できますか視点？
回答の例には、次のようなものがあります。低速で、拡張性が低く、拡張可能なデータ層の最も一般的な原因は何ですか。+この問題を解決するために（設計またはリファクタリングで）どのような対策を講じることができますか？
私はここで戦争の話と、公に入手可能なガイダンス文書とサンプルに組み込むことができるいくつかの現実世界のアドバイスを探しています。
魔法。
データベースからオブジェクトを自動的に保存およびフェッチするHibernateを使用しました。また、遅延読み込みもサポートしているため、関連するオブジェクトは、要求された場合にのみデータベースから取得されます。これは私が理解できない魔法のように機能します。
これは、機能している限りすべて正常に機能しますが、故障した場合、追跡することはできません。HibernateをAOPと組み合わせたときに、コードの実行時にオブジェクトがHibernateによってまだ初期化されていないという問題があったと思います。Hibernateはそのような不思議な方法で動作するため、この問題をデバッグするのは非常に困難でした。
オブジェクトリレーショナルマッピングは悪い習慣です。つまり、「リレーショナル」として大まかにしか説明できないデータスキーマが生成される傾向があるため、スケーリングが不十分で、データの整合性が低くなります。
これは、適切なリレーショナルスキーマが正規化のプロセスを経ているのに対し、ORマッピングの結果は通常データベーステーブルとして実装されたオブジェクトクラスであるためです。これらは通常は正規化されていませんが、代わりにOO開発者の即時の便宜のために設計されています。
もちろん、永続的なデータ要件が最小限である場合、これは重要ではありません。
しかし、私はかつて、他の複数の会社を買収して成長し、統合運用システムの開発を（継承したさまざまな会社固有のシステムを置き換えるために）OO手法を使用する会社にアウトソーシングしていた海運会社で働いていました。 ORマッピングによって生成されたデータスキーマ。開発中のシステムのパフォーマンス特性は非常に悪く、データスキーマは非常に複雑であったため、船会社は2年ほどの開発の後、システムが稼働する前にシステムを削除しました。
これは、ORマッピングの直接の結果でした。スキーマの最悪の複雑さ（およびその結果としてのパフォーマンスの低下）は、オブジェクト指向デザインプロセスのアーティファクトとしてのみ作成されたテーブルの存在によって引き起こされました-それらはデータの関係ではなく画面レイアウトを反映していました。