MongoDB Updating Denormalised Data [duplicate]
This question already has an answer here:
MongoDB relationships: embed or reference?
10 answers
Mongoose populate vs object nesting
1 answer
I am looking at modelling some data in MongoDB. Say for example a product has a supplier , and I want to embed the supplier name in the product
{
sku: 'prd1',
name: 'Product one',
supplier: {
supplierId: '5a37112f70467f45ec871e5b'
code: 'sup01',
name: 'Supplier One'
}
}
supplierId = the object id of the record in the supplier collection.
The supplier name would very rarely , if ever be updated. But if it does update , I need to be able to update all the embedded names in where that supplier is in a product.
I'm not overly familiar with Firebase , but it seems ( Reading This Blog Post ) that there is a mechamism called "multi-path updates" which solves this problem. Is there something similar in MongoDB , or do I need to manually keep track of all places the data exists and write my own code to update it?
mongodb
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
marked as duplicate by Neil Lunn mongodb
Users with the mongodb badge can single-handedly close mongodb questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 14 '18 at 22:09
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
MongoDB relationships: embed or reference?
10 answers
Mongoose populate vs object nesting
1 answer
I am looking at modelling some data in MongoDB. Say for example a product has a supplier , and I want to embed the supplier name in the product
{
sku: 'prd1',
name: 'Product one',
supplier: {
supplierId: '5a37112f70467f45ec871e5b'
code: 'sup01',
name: 'Supplier One'
}
}
supplierId = the object id of the record in the supplier collection.
The supplier name would very rarely , if ever be updated. But if it does update , I need to be able to update all the embedded names in where that supplier is in a product.
I'm not overly familiar with Firebase , but it seems ( Reading This Blog Post ) that there is a mechamism called "multi-path updates" which solves this problem. Is there something similar in MongoDB , or do I need to manually keep track of all places the data exists and write my own code to update it?
mongodb
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
marked as duplicate by Neil Lunn mongodb
Users with the mongodb badge can single-handedly close mongodb questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 14 '18 at 22:09
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Ah! You read the first article you found that matched the words that came in to describe your problem. However that is not actually what that "firebase feature" is about. They are talking about updating objects with "varying key name structures", and that is something MongoDB definitely does not do. But if has nothing to do with "keeping relations", despite the wording of the article title matching your own expected explanation of your situation.
– Neil Lunn
Nov 14 '18 at 22:05
Bottom line here is that if you are expecting something to "manage" where you have"sup01"and you want to change the attached name to"Supplier Uno", then that is a product of "relational design". The trade-off with MongoDB is that "repeating that name" everywhere as you have is faster than going and looking it up from another source. The other side of that trade-off* is of course the speed comes at the cost of storage and maintenance. So in essence it's up to you to manage yourself.
– Neil Lunn
Nov 14 '18 at 22:08
add a comment |
This question already has an answer here:
MongoDB relationships: embed or reference?
10 answers
Mongoose populate vs object nesting
1 answer
I am looking at modelling some data in MongoDB. Say for example a product has a supplier , and I want to embed the supplier name in the product
{
sku: 'prd1',
name: 'Product one',
supplier: {
supplierId: '5a37112f70467f45ec871e5b'
code: 'sup01',
name: 'Supplier One'
}
}
supplierId = the object id of the record in the supplier collection.
The supplier name would very rarely , if ever be updated. But if it does update , I need to be able to update all the embedded names in where that supplier is in a product.
I'm not overly familiar with Firebase , but it seems ( Reading This Blog Post ) that there is a mechamism called "multi-path updates" which solves this problem. Is there something similar in MongoDB , or do I need to manually keep track of all places the data exists and write my own code to update it?
mongodb
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
This question already has an answer here:
MongoDB relationships: embed or reference?
10 answers
Mongoose populate vs object nesting
1 answer
I am looking at modelling some data in MongoDB. Say for example a product has a supplier , and I want to embed the supplier name in the product
{
sku: 'prd1',
name: 'Product one',
supplier: {
supplierId: '5a37112f70467f45ec871e5b'
code: 'sup01',
name: 'Supplier One'
}
}
supplierId = the object id of the record in the supplier collection.
The supplier name would very rarely , if ever be updated. But if it does update , I need to be able to update all the embedded names in where that supplier is in a product.
I'm not overly familiar with Firebase , but it seems ( Reading This Blog Post ) that there is a mechamism called "multi-path updates" which solves this problem. Is there something similar in MongoDB , or do I need to manually keep track of all places the data exists and write my own code to update it?
This question already has an answer here:
MongoDB relationships: embed or reference?
10 answers
Mongoose populate vs object nesting
1 answer
mongodb
mongodb
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
asked Nov 14 '18 at 19:59
Martin ThompsonMartin Thompson
4762823
4762823
marked as duplicate by Neil Lunn mongodb
Users with the mongodb badge can single-handedly close mongodb questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 14 '18 at 22:09
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Neil Lunn mongodb
Users with the mongodb badge can single-handedly close mongodb questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 14 '18 at 22:09
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Ah! You read the first article you found that matched the words that came in to describe your problem. However that is not actually what that "firebase feature" is about. They are talking about updating objects with "varying key name structures", and that is something MongoDB definitely does not do. But if has nothing to do with "keeping relations", despite the wording of the article title matching your own expected explanation of your situation.
– Neil Lunn
Nov 14 '18 at 22:05
Bottom line here is that if you are expecting something to "manage" where you have"sup01"and you want to change the attached name to"Supplier Uno", then that is a product of "relational design". The trade-off with MongoDB is that "repeating that name" everywhere as you have is faster than going and looking it up from another source. The other side of that trade-off* is of course the speed comes at the cost of storage and maintenance. So in essence it's up to you to manage yourself.
– Neil Lunn
Nov 14 '18 at 22:08
add a comment |
Ah! You read the first article you found that matched the words that came in to describe your problem. However that is not actually what that "firebase feature" is about. They are talking about updating objects with "varying key name structures", and that is something MongoDB definitely does not do. But if has nothing to do with "keeping relations", despite the wording of the article title matching your own expected explanation of your situation.
– Neil Lunn
Nov 14 '18 at 22:05
Bottom line here is that if you are expecting something to "manage" where you have"sup01"and you want to change the attached name to"Supplier Uno", then that is a product of "relational design". The trade-off with MongoDB is that "repeating that name" everywhere as you have is faster than going and looking it up from another source. The other side of that trade-off* is of course the speed comes at the cost of storage and maintenance. So in essence it's up to you to manage yourself.
– Neil Lunn
Nov 14 '18 at 22:08
Ah! You read the first article you found that matched the words that came in to describe your problem. However that is not actually what that "firebase feature" is about. They are talking about updating objects with "varying key name structures", and that is something MongoDB definitely does not do. But if has nothing to do with "keeping relations", despite the wording of the article title matching your own expected explanation of your situation.
– Neil Lunn
Nov 14 '18 at 22:05
Ah! You read the first article you found that matched the words that came in to describe your problem. However that is not actually what that "firebase feature" is about. They are talking about updating objects with "varying key name structures", and that is something MongoDB definitely does not do. But if has nothing to do with "keeping relations", despite the wording of the article title matching your own expected explanation of your situation.
– Neil Lunn
Nov 14 '18 at 22:05
Bottom line here is that if you are expecting something to "manage" where you have
"sup01" and you want to change the attached name to "Supplier Uno", then that is a product of "relational design". The trade-off with MongoDB is that "repeating that name" everywhere as you have is faster than going and looking it up from another source. The other side of that trade-off* is of course the speed comes at the cost of storage and maintenance. So in essence it's up to you to manage yourself.– Neil Lunn
Nov 14 '18 at 22:08
Bottom line here is that if you are expecting something to "manage" where you have
"sup01" and you want to change the attached name to "Supplier Uno", then that is a product of "relational design". The trade-off with MongoDB is that "repeating that name" everywhere as you have is faster than going and looking it up from another source. The other side of that trade-off* is of course the speed comes at the cost of storage and maintenance. So in essence it's up to you to manage yourself.– Neil Lunn
Nov 14 '18 at 22:08
add a comment |
0
active
oldest
votes
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ah! You read the first article you found that matched the words that came in to describe your problem. However that is not actually what that "firebase feature" is about. They are talking about updating objects with "varying key name structures", and that is something MongoDB definitely does not do. But if has nothing to do with "keeping relations", despite the wording of the article title matching your own expected explanation of your situation.
– Neil Lunn
Nov 14 '18 at 22:05
Bottom line here is that if you are expecting something to "manage" where you have
"sup01"and you want to change the attached name to"Supplier Uno", then that is a product of "relational design". The trade-off with MongoDB is that "repeating that name" everywhere as you have is faster than going and looking it up from another source. The other side of that trade-off* is of course the speed comes at the cost of storage and maintenance. So in essence it's up to you to manage yourself.– Neil Lunn
Nov 14 '18 at 22:08