CODEWITHSUNDEEP
hibernatejpa
kosa
kosa

Reputation: 66637

Hibernate associations Vs Hibernate property

I did some level reading but couldn't able to find out proper answer, that is why this theory question:

I have a case where, there are lot of many-one mappings across data model (with default fetch strategy). As data grows (with few thousand records), retrieval performance is very bad. When I look at generated queries I have observed that lot of Joins.

Part of fine tuning process, I am trying to remove/modify un-necessary associations, starting with bi-directional.

My question is: Do we need associations at all (could be one-may/many-many) if we don't need navigational comfort. What may be an issue if we simply remove association in hbm file and make it is as non-null property.

Example: (Just for understanding purpose, this is not real case).

<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>

If I change Shelf like below, would I be breaking any data modeling principles?

 <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>

Any input would be appreciated.

Upvotes: 0

Views: 68

Answers (1)

V G
V G

Reputation: 19002

That, what you made in your example, makes sense ONLY in rare cases (e.g we used it when we wanted to separate 2 modules, that had to remain unknown to each other, one module being reused in different projects).

On the other hand, the LAZY Fetch type is the way to go, because it is backward compatible with the current behavior (if you get later some problems, you will simply revert the FetchType and the DB will not suffer any modifications) and you will still be able to navigate to other entities in future if you will need it. Besides this is how you model things in a POO language.

If you still have any performance problems with the FetchType.Lazy option, you should try to solve them instead (although I doubt you will get any performance improvements with your example).

PS: May be, there will be someone who will give a better answer, but I will try to answer the question.

Upvotes: 1

Related Questions