0

私はいくつかのレベルの読書をしましたが、適切な答えを見つけることができませんでした。それがこの理論の質問です:

私は、データモデル全体で多くの1つのマッピングがある場合があります(デフォルトのフェッチ戦略を使用)。データが大きくなるにつれて (数千レコード)、検索パフォーマンスは非常に悪くなります。生成されたクエリを見ると、多くのJoins.

微調整プロセスの一環として、双方向から始めて、不要な関連付けを削除/変更しようとしています。

私の質問は次のとおり です。ナビゲーションの快適さが必要ない場合、関連付けはまったく必要ですか (1 つまたは複数の可能性があります)。hbm ファイルの関連付けを単純に削除し、null 以外のプロパティとして作成すると、何が問題になる可能性がありますか。

例: (目的を理解するためだけに、これは実際のケースではありません)。

<class name="Book" table="BOOK">
        <property name="name" type="string">
            <column name="Name" length="50" not-null="true" />
        </property>
</class>

<class name="Shelf" table="SHELF">
        <property name="code" type="string">
            <column name="CODE" length="50" not-null="true" />
        </property>
       <one-to-many class="Book" column="bookId" />
</class>

Shelf以下のように変更すると、データ モデリングの原則に違反することになりますか?

 <class name="Shelf" table="SHELF">
        <property name="code" type="string">
            <column name="CODE" length="50" not-null="true" />
        </property>
       <property column="bookId" not-null="true"/>
 </class>

任意の入力をいただければ幸いです。

4

1 に答える 1

1

それは、あなたの例で作成したものは、まれなケースでのみ意味があります (たとえば、2 つのモジュールを分離したい場合に使用し、2 つのモジュールは互いに未知のままにしておく必要があり、1 つのモジュールは異なるプロジェクトで再利用されます)。

一方、LAZY Fetch タイプは、現在の動作と下位互換性があるため、進むべき道です (後で問題が発生した場合は、FetchType を元に戻すだけで、DB は変更されません)。必要に応じて、今後も他のエンティティに移動できます。これは、POO 言語で物事をモデル化する方法です。

FetchType.Lazy オプションでまだパフォーマンスの問題がある場合は、代わりに解決を試みる必要があります (ただし、この例でパフォーマンスが改善されるとは思えません)。

PS: より良い回答をする人がいるかもしれませんが、私はその質問に答えようとします。

于 2013-10-23T16:12:13.173 に答える