is one to one relationship bad strategy

Question

User always has one Wallet. One Wallet belongs always to one User.

Since I want to separate money wallet related properties I was create Wallet object and to be able to track money transactions, ... I created

public Wallet : Entity<int>
{
    public double Amont {get; set;}
    public IList<MoneyTrans> Transactions {get; set;}
}

Since this is obviously one to one relationship is it ok to map using one to one relationship?

Is one to one bad strategy?

Answer 1

I had to append answer, with opposite point of view. Do not use one-to-one mapping. At least with NHibernate.

I am not talking about the conceptual domain driven design. Just about my experience with DB design and NHibernate usage.

1) one-to-one - Rigid DB design

First of all the desing with shared primary keys (except of inheritance) could lead to many issues later, when the Business requirements are changed.

The typical scenario, very similar to example 23.2. Author/Work, where Author is mapped one-to-one to Person. Therefore, the id (primary key) of the Author comes from a Person (id). Sooner or later, Business will come and ask could we have to person mapped to Author (see Lars Kepler example)

What I am trying to say here is: Chapter 24. Best Practices (let me cite one point)

Declare identifier properties on persistent classes.

NHibernate makes identifier properties optional. There are all sorts of reasons why you should use them. We recommend that identifiers be 'synthetic' (generated, with no business meaning) and of a non-primitive type. For maximum flexibility, use Int64 or String.

As mentioned here (and from my experience), it is very benefitial to have all entities with their own surrogated primary keys. The changes in relations coming later - will effect just references (on top of surrogated keys), not the table/entities themselves.

2) one-to-one with NHibernate cannot be lazy

In fact this reason is the one, why (despite of the fact I tried few times) currently do not use the one-to-one at all. The one-to-one is not supporting lazy loading. Search for more info but nice explanation could be found here:

• Ayende NHibernate one-to-one (a cite)

  In other words, one-to-one cannot be lazily loaded, which is one of the reasons why it is recommended to use two many-to-one instead.

• Some explanations on lazy loading (one-to-one)

As mentioned in one of the links in comments below the question (cite)

1. You can either include all those attributes as columns into your entity table - but in that case, lots of columns would end up empty for a significant number of the entries.

2. Or: you can put those "optional" attributes into a separate table, set up a 1:1 (or rather: 0:1) relationship with the base entity table,

Well, with NHiberante you won't get so much improvement. This suggestion is wrong. Lazy loading of one-to-one isn't supported...

SUMMARY:

That's why I would strongly suggest: use many-to-one or one-to-many where possible. You'll gain more...

Answer 2

No it's fine. It's not just about relationships but object orientation. Fundamentaly a Wallet is not an unseverable part of a Person.

Looking beyond that, whilst the wallet might belong to a specific 'John' now, 'James' might be given it as a present. From the data perspective it's much better to just change the WalletId fields of John and James of which one may be null (although not in your case) if they don't have a wallet.