I'm designing a NoSQL database schema - MongoDB in particular - and I'm wondering if it's a good idea not to embed certain one-to-one relationships.
For one example, I have an
accounts collection, which stores all the account information. The account balance requires some calculation to compute, and I see two options:
- Have a
cached_balancefield on the
accountscollection, which starts off as null. Whenever the balance is recomputed, the field for the relevant account is updated.
- Have an
account_balances_cachecollection with a one-to-one relationship with
accounts. Whenever the balance is recomputed, the relevant field in this collection is updated.
The benefit of the embedded document is that I get all the information in one join. A separate collection would require an application-level join which is not as wieldy.
However, the reason I thought of having a separate collection is because I like the conceptual separation of it. There is one collection for all the important data that must not be lost, and there's another with data that could be recomputed at any time, where the entire collection could be dropped and nothing of ultimate value will have been lost. Or it could even be in another database which could be kept on a different server, etc. Is this sound reasoning or am I just making it unnecessarily difficult for myself?
(Note that this is a simplified example. In actuality the things in these caches may be hard/computationally expensive to compute, which is why I'm putting them in the database as well instead of something like redis or memcached.)