I wanted to implement “The extended reference pattern” but I have questions about the implementation

Working with Data
,
1

hey,

I am new with MongoDB and I would like to have your help in the implementation of my schema, I have 2 collections User and Order, it’s One-to-Many Relationships.

After reading about different schemas I understood I wanted to implement “The extended reference pattern” but I have questions about the implementation.

I understood that this pattern means to embed only part of the data from the collection but still have a separate collection with all the data.

in my case, I want to embed the email field from the User collection(separate class, not embedded document class) in the Order collection as a field.

first, I am not sure I understood the implementation of this pattern, does it means to have 2 classes, in my case- one class that is the User which is not EmbeddedDocument and another class that is EmbeddedDocumnet only with the fields I want them to be and that will probably will not change.

second, if it does like that, in my case it seems unnecessary because I have only one field I wish to embed, so should I just need to add a new regular field called email in the order class?
I’m a little confused about how this pattern is actually implemented and how should I implement it.
In the user collection, I have other fields that may change frequently so I didn’t wanna use the reference field.

thanks for any help!

2

Hi @meshi_biton ,

Welcome to MongoDB community.

I am not completely certain what do you mean by embedding classes as it depends on your logic and framework who perform the eventual write of data to embed the details of a user into the order collection.

However, it make sense to take the immutable or rarely frequency updated fields and place them into the many collection.

In your case I would expect something like:

order collection

{
_id : ... , 
Items : [ ... ],
User : { userId : ... , Email : ... }
...
}

Now who pushes this data into that document is up to the application. If you can pass the user class into the order process and have a method to fetch all the reference related data you can call it in the order creation process.

Additionally, wanted to to note that sometimes even frequently changed field might be embedded if it make sense to store the value as it was in time of order. Any chance in the future should not change the historical order data.

For example a billing address. My billing address might change often as I travel but for an order the billing address is the effective one I had when I made it.

I recommend reading the following

Thanks
Pavel

3

thank you for your quick answer! I really appreciate it, but I am still confused about this pattern. I watch this video of MongoDB (https://youtu.be/8CZs-0it9r4) which explains what it means but I didn’t understand how it should implement?. (i wrote my assumption in the post)
from your answer, I suppose in my case I should add a field(not embedded field ) in the order collection with the email address in each order.
the rest of the fields of the user are not necessary for the order.
And thank you for your advice!

4

i read the article and i would like to understand what it means “we only embed those fields of the highest priority and most frequently accessed” how we do that?
the user have other fields ,assume i want to embed only the fields -id and email.
should i create another class(Embeded class) with those fields? .

5

@meshi_biton , by embedding the article means is we copy this content we don’t actually take one class and place it in the other.

We duplicating content for fast access and to avoid the need to join data like in sql normalized schema …

6

okay, now I understand, I really appreciate your help,thank you!=)

1 Like