I am deciding upon M:M relationship. I have two tables Investors and MutualFunds. And Below is the relationship.
Mandatory Many (Investors Table) : optional Many (MutualFunds Table)

When I create the mapping file for these two tables. Shall I go for relationship ? because MutualFunds table has optional record.

Any thought?

Thanks

Sure. Many-to-many collections are not required to contain anything. "Many" means "Zero or more".

Basically, you should stick to the following rule.

1:1 (Mandatory to Optional) - No Relationship
1:1 (Optional to Optional) - No Relationship
1:1 (Mandatory to Mandatory) - One-to-One Relationship
M:1 (Mandatory to Optional) - No Relationship
M:1 (Optional to Optional) - No Relationship
M:1 (Mandatory to Mandatory) - Many-to-One Relationship
M:M (Mandatory to Mandatory) - Many-to-Many Relationship
M:M (Optional to Mandatory ) - No Relationship
M:M (Mandatory to Optional) - No Relationship

Correct me if I am wrong.

Thanks
Rashid

That doesn't look right. Why would you have no relationship between two related entities, even if they're optional? No foreign key constraint, possibly (thought I'd argue against that, too), but you should have a mapped relationship in all of those cases.

All the tables in the DB, directly or indirectly are related to each other. If the DB has 100 tables and most of them will be related to each other (directly or inderectly) then shall we go for all the relation defenition mapping? Probably, we shoukd look into PK and FK constraint and then define the relationship even if there is optional relation (Zero or More).
Coming back to originak posting.



So in these scenario, an investor may or may not havevMutualFund. So, can we have relationship here? Assuming PK and FK constaint exists.

In my opinion, yes. Even if the entire DB is connected via FK relationships, hibernate will handle it gracefully, because of its lazy initialization support. It's more complex to deal with the occasional ID-as-a-property, and joining in queries, etc.; fob all that off onto hibernate, and concern yourself with writing the important business logic code.

You don't even need FK relationships. If you can relate two tables, then express that relationship in hibernate. Never deal with IDs as properties: IDs are handles to entities, not values.

Thats true, I did some research and concluded that we should have relationship even if for optional entity. And, based on our requirement we do the relationship mapping.