0

I know that, generally speaking, if a one-to-one relationship exists between two documents I should consider embedding one document within the other. I do, however, have a few scenarios where this doesn't feel right, primarily in scenarios where I need to query on properties of the embedded document. What I have done instead is to create a relationship between the ids (primary keys) of the two documents by using a convention.

For example, a User has a PasswordResetLog. The user and the log are represented by separate documents. If the user document id is 'users/123' then the corresponding password reset log document id is 'passwordresetlog/123'.

Since I almost always have access to the userId I can easily load documents associated with it in this manner.

My first question is: will this create fragmented indexes for the documents where I specifically set the ids by convention? The document ids are sequential, but I cannot alway guarantee that they'll be created in sequential order.

My second question is: Instead of using this convention, should I just add a property UserId on each document that is in a one-to-one relationship with User, and add an index for this property?

Øyvind
  • 1,600
  • 1
  • 14
  • 33
  • why do you need to index the password reset log doc anyway? Are you going to search for it? More likely is that you'll always be loading that by id, no? – Ayende Rahien Aug 15 '15 at 00:16
  • I will, more often than not, load it by id. My question is whether my id strategy, whereby I create the id of the password reset log based on the id of the user, is one that will cause problems in the long run? – Øyvind Aug 16 '15 at 11:14
  • No, it shouldn't. I recommend keeping the pass reset log id in the user document anyway (to make loading it via include easier), though. – Ayende Rahien Aug 17 '15 at 12:03
  • OK, great! And the point about storing the password reset log id in the user document is duly noted. If you post your comment as an answer I'll accept it! – Øyvind Aug 17 '15 at 20:27

0 Answers0