I want to manage multiple projects data in mongoDB. Each project contains multiple users from multiple departments with multiple role assigned to them. plus certain task is assigned to each user. Now I am confused about schema, not able to decide which entity should be kept as collection & which one as document ? What is the best efficient way to store ?
should I keep all under single collection as embedded documents or in separate collection ?
Thanks
First of all if you are using mongodb you should know why are you using it. MongoDB is not about normalize stuff. If you are able to create data structure is de-normalize way then and only then go for MongoDB.
I think you should maintain one single document containing all the mentioned things above. But the scenario which you have mentioned above is good for relational database. you need only 3 entities in relational database and your problem is solved.
Still if you want to go for mongodb you can go with one collection only. which contains project details number of users working there and their roles and department.
Related
Im working on a project using flutter and firebase, currently the database(firestore) has A collection named Projects, each project has an owner(userId) and a subcollection named Sections and each section has an Items collection. Each Item has a list of tags (strings). I wanted to add a search Items by tag feature, but just realized that the nested collections structure makes it hard. Changing the database structure now would be a lot of work. Is there a way to apply a query to multiple subcollections? basically I would need to query all projects owned by the user then query for all in those projects sections and then all todos inside them that contain a certain tag.
I don`t want to do multiple queries and join them with frontend code because I'm using real time functionality and having to deal with multiple streams isn't ideal. Cloud functions aren't an option right now because I'm using the free plan.
You're looking for a so-called collection group query, which searches across all collections with a certain name in one go.
I am trying to come up with a rough design for an application we're working on. What I'd like to know is, if there is a way to directly map a one to many relation in mongo.
My schema is like this:
There are a bunch of Devices.
Each device is known by it's name/ID uniquely.
Each device, can have multiple interfaces.
These interfaces can be added by a user in the front end at any given
time.
An interface is known uniquely by it's ID, and can be associated with
only one Device.
A device can contain at least an order of 100 interfaces.
I was going through MongoDB documentation wherein they mention things relating to Embedded document vs. multiple collections. By no means am I having a detailed clarity over this as I've just started with Mongo and meteor.
Question is, what could seemingly be a better approach? Having multiple small collections or having one big embedded collection. I know this question is somewhat subjective, I just need some clarity from folks who have more expertise in this field.
Another question is, suppose I go with the embedded model, is there a way to update only a part of the document (specific to the interface alone) so that as and when itf is added, it can be inserted into the same device document?
It depends on the purpose of the application.
Big document
A good example on where you'd want a big embedded collection would be if you are not going to modify (normally) the data but you're going to query them a lot. In my application I use this for storing pre-processed trips with all the information. Therefore when someone wants to consult this trip, all the information is located in a single document. However if your query is based on a value that is embedded in a trip, inside a list this would be very slow. If that's the case I'd recommend creating another collection with a relation between both collections. Also for updating part of a document it would be slow since it would require you to fetch the whole document and then update it.
Small documents with relations
If you plan on modify the data a lot, I'd recommend you to stick to a reference to another collection. With small documents, this will allow you to update any collection quicker. If you want to model a unique relation you may consider using a unique index in mongo. This can be done using: db.members.createIndex( { "user_id": 1 }, { unique: true } ).
Therefore:
Big object: Great for querying data but slow for complex queries.
Small related collections: Great for updating but requires several queries on distinct collections.
I just wanted to query everyone's best practice for doing this.
User has multiple notebooks within their account. Each of these is a record in the database.
There are multiple users.
The notebook has different sections to fill in. There are also sections which are lists. The user needs to be able to add extra items to these lists (almost as if it were it's own collection).
There may be a lot of users, and I want all their notebooks in the same collection.
How would you approach this? I'm using Simple Schema and Aldeed Collection. I imagine that each list within the notebook would be an array, but how would I make it that the user can set how many items / add new items to the list?
Interested to know people's thoughts!
This is a MongoDB data modeling question primarily (see also schema design), but there are a few things to keep in mind with Meteor:
read up on reactive joins at Discover Meteor and Gentle Node
for reactivity to work at its best, you want collections instead of arrays
that means you'll need to perform the equivalent of joins with MongoDB, so have a look at reactive join packages, this post about evaluating them, and Meteor.publish: publish collection which depends on other collection
Make sure to vote up this card on the Meteor roadmap to get native reactive joins.
I am new to MongoDB.I have one Master Collection user_group.The sample document is shown bellow.
{group_name:"xyz","previlege":["Add","Delete"],...}
And second collection user_detail
{"user_name":"pt123","group_name":"xyz",...}
How can I maintain relation between these two collections.Should I use reference from user_group into user_detail or any other alternative?
Often, in MongoDB, the "has many" relationship is managed on the opposite side as in a relational database. A MongoDB document often will have an array of ObjectIds or group names (or whatever you're using to identify the foreign document). This is opposed to a relational database where the other side usually has a "belongs to" column.
Do be clear, this is not required. In your example, you could store an array of user details IDs in your group document if it was the most common query that you were going to make. Basically, the question you should ask is "what query am I likely to need?" and design your documents to support it.
Simple answer: You don't.
The entire design philosophy changes when you start looking at MongoDB. If I were you, I would maintain the previlege field inside the user_detail documents itself.
{"user_name":"abc","group_name":"xyz","previlege" : ["add","delete"]}
This may not be ideal if you keep changing group priviledges though. But the idea is, you make design your data storage in a way so that all the information for one "record" can be stored in one object.
MongoDB being NoSQL does not have explicit joins. Workarounds are possible, but not recommended(read MapReduce).
Your best bet is to retrieve both the documents from the mongo collections on the client side and apply user specific privileges. Make sure you have index on the group_name in the user_group collection.
Or better still store the permissions[read, del, etc] for the user in the same document after applying the join at the client side. But then, you cannot update the collection externally since this might break invariants. Everytime an update to the user group occurs, you will need to apply those permissions(privileges) yourself at the client side and save those privileges in the same document. Writes might suffer but reads will be fast(assuming a few fields are indexed, like username).
I want to create only the collections structure.
i.e.
Say Products collection contains a list of Categories.
I want to specify this container structure by creating this dependencies, but I do not want to create any collection entry (say there is a loader program somewhere that bulk uploads the data).
The closet analogy in RDBMS is; DBA creates the schema design with constraints and dependencies; application or ETL tool loads the actual data.
Most of the examples that I see simply create a sample collection and then invoke the
db.insert(document)
OR
db.save(document)
Is it even possible in MongoDB?
if the question is not clear, please let me know.
Thanks
The short answer is NO.
You cannot create a schema in MongoDB. A collection is just a set of documents. Furthermore, dependencies are likely to be represented with embedded documents (as opposed to referenced documents).
We can be more specific if you post the data you want to represent.