I have MERN application, I have a bunch of collections in my db, now i want to store an object that represents an order:
Say i have "item1, item2, item3" in an "items" collection, each one can be anything really;
I just need the Id's (to reference them), I want the user to choose their order so that i know the correct way of displaying the items (Not the order in the db, an order for a seprate purpose)
I think the best way of doing it is having a single document, with the order data in it, but each document should be in a collection, so the question is, is it right to create a collection only to store a single document in it? or is there a better way?
This is an example of the document i want to store: (The array index is their order)
{
items: [{itemId:xxx, otherprops...}, {itemId: yyy, otherprops...}]
}
The items collection can have 100s of items, so changing the order in that collection is not the correct option for my needs.
is it right to create a collection only to store a single document in
it
If you look at the admin database in mongodb, you'll see that it does something similar to what I think you're trying to do. There's a system.version collection. In that collection, I've seen documents that contain settings-like information. For example, the featureCompatibility property is actually stored as a document with _id: "featureCompatibility". Shard identity information is also stored as a single document in this collection:
{
"_id" : "shardIdentity",
"clusterId" : ObjectId("2bba123c6eeedcd192b19024"),
"shardName" : "shard2",
"configsvrConnectionString" : "configDbRepl/alpha.example.net:28100,beta.example.net:28100,charlie.example.net:28100" }
There is only one such document in the system.version collection. You can very well create your own settings collection where you store these bespoke documents. It's certainly not unheard of.
Take a look at the "Shard Aware" section from the official mongodb documentation to see this type of practice in action:
https://docs.mongodb.com/manual/release-notes/3.6-upgrade-sharded-cluster/#prerequisites
Related
I have a Firebase database with a list of entries. Now, on click, I want to copy a certain document from this database to a user database (create new document in user DB) while at the same time updating one of the fields.
I figured out how to copy the document, but I have problems with updating the field. I think I'm simply using a wrong syntax, but couldn't find this example in Firebase documentation.
This is how the original document looks like: (https://i.stack.imgur.com/ux18x.png)]
And this is how it's copied into the user database: (https://i.stack.imgur.com/QsBVy.png)]
I use this code to make the copy:
setDoc(doc(userSentencesRef, newSentenceIDText), ...newSentence)
And I tried many ways to update the "Level" field, but none of them works:
setDoc(doc(userSentencesRef, newSentenceIDText), ...newSentence, {data: {LEVEL: "exclude"}})
setDoc(doc(userSentencesRef, newSentenceIDText), ...newSentence, {LEVEL: "exclude"})
setDoc(doc(userSentencesRef, newSentenceIDText), {...newSentence, LEVEL: "exclude"})
(the first two do nothing, the last one adds a separate level field).
I also wouldn't want to list every single field that needs to be added { EN: data.EN, DE: data.DE }, etc, because I want to make sure it works even if the other fields change in future.
I will really appreciate your help.
I am using Reactjs and Firestore.
I have this collection of products:
The colorMap is a map then below it are the different colors and their quanty.
Now, I want to create a list or a history whenever a product is added and whenever the quantity in those colors was added more of it.
Should I add another collection that will store when a product is added or whenever quantities are added in the color? I'm also thinking of adding a createdDate
Or there any other way I could do this? As much as possible, I won't be using any cloud functions.
A common way to keep the history of each document is by creating a subcollection under that document (say history) and writing a new document with either the complete, old document data there for every update you perform, or a new document with just the old values of the fields that were modified.
While it is convenient to do this from Cloud Functions, as they already get both the previous and the new data for each document write, you can accomplish the same from client-side code too.
I am creating a tag based search engine for various kind of things in mongodb.
I have blogs document, testimonials document, comments documents, books document and images document and all these have array of tags field.
Now when I fetch a book, which have certain tags associated with it, I would like to also fetch blogs and testimonials and comments with those tags.
I would like to the same when I fetch a blog .. fetch rest with tags that blog have.
I am designing my database model. what is the best way to handle these kind of tag based search.
currently what I am thinking is
add tags in each document
at fetch , take tag and search through all other document
take the result and then send with result
is this the best way ? how should I design model?
Update :
I will perform search more frequently.
If you need to repeat tags in multiple collections, I would rather do a tags collection itself.
Why would I move tags into their own collection?
Think if you need to change the name of one tag in the future, maybe because of a mistake like a typo, you'll need to iterate over all your collections searching for this tag to fix it. Wouldn't it be easier if you only need to replace in one place?
Embed arrays and objects in one document is a powerful tool, but there are times when it's not the best solution. This case is one of them, and you should prevent as much as you can repetition.
Official documentation talking about avoid repetition.
Collection Structure
Create a tags collection and add their ObjectId to the tags array in the other documents instead of the tag itself. Like below.
// tags collection
{
_id: <ObjectId1>
title: "trending"
}
// all other documents (blogs, testimonials...)
{
_id: <ObjectId2>
tags: [
<ObjectId1>
],
// other stuff...
}
Fetching tag related documents in one hit
When you fetch one document you can get all its tags and look for other documents with related tags using the operator $in, like this:
db.blogs.find({
tags: {
$in: [
<ObjectId1>,
<ObjectIdX>,
// other tags ids
]
}
})
And this will return at once all the documents matching one or more tags.
More about $in operator.
Other tips
Well used indexes have a great impact on performance. This isn't the place to teach about how they works, but mongodb have multikey indexex and in your concrete case is obviuos which one, tags.
Example:
db.blogs.createIndex( { "tags": 1 } )
When is it appropriate to filter a collection vs. having several collections in Backbone?
For example, consider a music library app. It would have a view for displaying genres and another view for displaying the selected genre's music.
Would you rather make one huge collection with all the music and then filter it or several smaller ones?
Having just one collection would allow you add features for filtering by other attributes as well, but suppose you have tons of music: how do you prevent loading it all in when the application starts if the user if only going to need 1 genre?
I think the simplest approach is having a common unique Collection that, intelligently, fetch an already filtered by genre data from the server:
// code simplified and no tested
var SongsCollection = Backbone.Collection.extend({
model: Song,
url: function() {
return '/songs/' + this.genre;
},
initialize: function( opts ){
this.genre = opts.genre;
}
});
var mySongsCollection = new SongsCollection({ genre: "rock" });
mySongsCollection.fetch();
You have to make this Collection to re-fetch data from the server any time the User changes the selected genre:
mySongsCollection.genre = "punk";
mySongsCollection.fetch();
It's mostly a design choice, but my vote would be to choose a scheme that loosely reflects the database storing the collections.
If you're likely to be storing data in an SQL database, you will more likely than not have separate tables for songs and genres. You would probably connect them either via a genre_id column in the song table, or (if songs can have more than one genre) in terms of a separate song_genres join table. Consequently, you would probably want separate collections representing genres and the songs within them. In this case, backbone-relational might be very useful tool for helping keep them straight.
If you're storing information in any kind of relational/key-value/document store, it might make sense to simply store the genre with the song directly and filter accordingly. In this case, you might end up storing your document keys/queries in such a way that you could access songs either directly (e.g., via songs) or through the genre (e.g., genre:genre_id/songs). If this is the route you go, it may be more convenient to simply create a single huge collection of songs and plan to set up corresponding filters in both the application and database environment.
I need a CouchDB view where I can get back all the documents that don't have an arbitrary field. This is easy to do if you know in advance what fields a document might not have. For example, this lets you send view/my_view/?key="foo" to easily retrieve docs without the "foo" field:
function (doc) {
var fields = [ "foo", "bar", "etc" ];
for (var idx in fields) {
if (!doc.hasOwnProperty(fields[idx])) {
emit(fields[idx], 1);
}
}
}
However, you're limited to asking about the three fields set in the view; something like view/my_view/?key="baz" won't get you anything, even if you have many docs missing that field. I need a view where it will--where I don't need to specify possible missing fields in advance. Any thoughts?
This technique is called the Thai massage. Use it to efficiently find documents not in a view if (and only if) the view is keyed on the document id.
function(doc) {
// _view/fields map, showing all fields of all docs
// In principle you could emit e.g. "foo.bar.baz"
// for nested objects. Obviously I do not.
for (var field in doc)
emit(field, doc._id);
}
function(keys, vals, is_rerun) {
// _view/fields reduce; could also be the string "_count"
return re ? sum(vals) : vals.length;
}
To find documents not having that field,
GET /db/_all_docs and remember all the ids
GET /db/_design/ex/_view/fields?reduce=false&key="some_field"
Compare the ids from _all_docs vs the ids from the query.
The ids in _all_docs but not in the view are those missing that field.
It sounds bad to keep the ids in memory, but you don't have to! You can use a merge sort strategy, iterating through both queries simultaneously. You start with the first id of the has list (from the view) and the first id of the full list (from _all_docs).
If full < has, it is missing the field, redo with the next full element
If full = has, it has the field, redo with the next full element
If full > has, redo with the next has element
Depending on your language, that might be difficult. But it is pretty easy in Javascript, for example, or other event-driven programming frameworks.
Without knowing the possible fields in advance, the answer is easy. You must create a new view to find the missing fields. The view will scan every document, one-by-one.
To avoid disturbing your existing views and design documents, you can use a brand new design document. That way, searching for the missing fields will not impact existing views you may be already using.