I'm new to MongoDB, and went with MongoMapper for some associations help.
I'm quite curious since, you see, I'm trying to establish some User<->Friend relationships, and I'm a little bit confused about the difference between Document and EmbeddedDocument.
I suppose User would be a Document, but would Friend be an EmbeddedDocument for User or a Document on its own that simply gets called (many :friends) by User?
In my preliminary design, a Friend's list would only be accessible through a User.
Thanks!
You're asking a basic "embed vs. reference" question that gets asked quite a bit when it comes to MongoDB. The answer is not always obvious.
Here's an extensive reply on a similar question. Here are the official MongoDB docs on this question.
One of the general rules:
"First class" objects, that are at top
level, typically have their own
collection.
In your case a Friend is probably a User object in itself. You probably don't want to Embed the entire Friend inside of the User. Instead, you probably want to keep a list of friends as an array inside of each User. (so probably the references)
Related
I am building a personal work/career portfolio web app project, and plan on using MongoDB for my database. (I plan to build the project using MERN stack.) Most of my data is not one-time data (such as education, and work experiences), however I have a few pieces of data (such as my personal summary (the content for my "About Me" section), and skills summary) that are one-time only data (I think "single instance" might be a better fitting term). I would like to store all of the data in a database, and set up an admin-end to manage and edit the data. However, I am not sure how to go about storing the one-time data in my MongoDB database.
One idea I had was to create a collection solely for the one-time data, and only allow the user (me) to update and read the documents in the collection. Another idea I had was placing all of my portfolio data into a single collection called "entries", and giving each "entry" a type (such as "Education", or "Personal Summary"). Then when I retrieve the data from the collection I would gather all the documents with the same value in their type field together. I was thinking of storing each of the types as a constant on my server. However, my biggest concern with both ideas is if they would be considered bad practice of not.
I would be very appreciative if anyone has any advice on how to solve this problem.
I had implemented this a while back on one of my small projects, and again after discussing it over with some professionals I'm in contact with, they said that the best approach would be to create a collection with a single document that contains all the information, like the links, about, etc...
One more thing I, was suggested is that we could use Redis solely for the purpose of storing this type of information as well.
Something that I implemented a long time back similar to the one collection, single doc approach: https://github.com/codelancedevs/Sundar-Clinic/tree/local-backend/src/api/app
Working on a similar approach here: https://github.com/kunalkeshan/Cam-O-Genics-Backend
Hope this is of some help, I'm still learning as to what might be the best approach. Open to any suggestions out there!
I am working on a react-native app using nodejs and mongodb on the backend. In my app users are able to create multiple accounts and there are different account types (Business, Artist, Venue, etc.). For the most part, each account type has the same data and fields in the database. Things like name, location, website. But it is possible for each account type to have a couple pieces of data specific to that account. My question is, should I simply have one "Account" collection in the database that stores all accounts and has an "accountType" field to differentiate each account?
Initially I thought to do the opposite and store each account type in a separate collection, but I found it made the client code pretty messy as I found myself adding a bunch of if statements to determine things like what api endpoint to make requests to, what components to render, and what screens to navigate to, when in reality, it's really just a couple pieces of data that may change from one account type to another.
It seems like having just one "Accounts" collection with an "accountType" field will greatly simplify the code. But maybe there is something I am missing. If anyone has some insight as to which approach may be better for the situation, or some of the pros/cons of each approach, I'd really appreciate the help! Thanks!
Well, the answer clearly depends on how the documents for different types of accounts differ. But, the idea of going with a single collection is fine, also take a look at the Subset Pattern, it's will give you a fine idea, of how to divide data into different collections, depending on their usage.
I am currently watching a how-to create an instagram clone for Swift and want to understand the data model for the comments.
What is the purpose of using a model for the comments like:
post-comment (key = post-id) and comments
over something like this, where every comment has the post-id in it?
Without knowing what exactly they're building, and the types of queries they need to support for the app, one can only guess that this post-comments collection satisfies the need for a query to find out which comments are a part of which posts, while still allowing queries that search all posts or all comments. You should find the part of the tutorial that queries this collection to find out what it's trying to do.
This tutorial might be kind of old, because this sort of thing would be a little bit easier to express today using collection group queries.
Not sure if collection is the right word but I'm trying to say whatever a table would be in MongoDB
I'm planning on making a switch from MySQL to MongoDB and have been reading up on it but one thing I can't seem to find much coverage on is one-to-many or many-to-many collections.
So say I have a forum collection, forum collection has many posts, as well there is a user collection which has many posts (posts is shared between forum and user so that you can see a users profile and see their posts as well when you visit the forum it will populate recent posts)
What would be the way I should be associating these, should I directly insert the post into both User and Forum collection that way I can just query the user and get their posts, or should I store the posts in forums with a userid and then query the forum collection for posts by a certain userid
Sorry for poor formatting as I am on mobile. This isn't specific to a forum it is just an example on the proper way to be storing One-To-Many collections. Thanks!
First, ask yourself why are you moving to MongoDB, MongoDB by definition is not a relational DB. If you want to achieve query performance, then the answer is to store the data twice and maintain it via code (when stuff are updated, update twice etc...).
If you don't have performance issues, consider keep it Mysql, cause holding relational data in MongoDB is less recommended since you don't really have transactions.
So there is no right or wrong, it's depends on what is the problem you are trying to solve.
I'm trying to model a simple, experimental app as I learn Symfony and Doctrine.
My data model requires some flexibility, so I'm currenty looking into the possibility of using either an EAV model, or document store in MongoDB.
Here's my basic requirements:
Users will be able to store and share their favourite things (TV prog, website, song etc).
The list of possible 'things' a user can store is unknown. For example, a user may want to store their favourite animal.
Users can share their favourite things with other users. However, a user can decide what he / she shares with each other user. For example, a user may share their favourite movie with one user, but not another.
A typical user will log in and view all the favourite things from their list of friends, depending on what his friends have decided to share. The user will also update their own favourite things, which will be reflected when each other users views their own profile. Finally, the user may change which of his friends can see what of his favourite thing.
I've worked a lot with Magento, which uses the EAV model extensively. However, I'm adding another layer of complexity by restricting which users can see what information.
I'm instantly drawn to MongoDB as the schemaless format gives me the flexibility I require. However, I'm not sure how easy (or efficient) it will be to access the data once it's saved. I'm also concerned about how changes to the data will be managed, e.g. a user changes their favourite film.
I'm hoping someone can point me in the right direction. This is purely a demo app I'm building to further my knowledge, but I'm treating it like a real-world app where data access times are super-important.
Modelling this kind of app in a traditional relational DB makes me sweat when I think about the crazy number of joins I'd need to get the data for one user.
Thanks for reading this far, and please let me know if I can provide anymore information.
Regards,
Fish
You need to choose a model based on how you need to access the data.
If you just need to filter out some values when viewing the user profile, a single document for each user would work quite well, with each favorite within that having a list of authorized user/group IDs that is applied in the application code. Both read and write are single operations on a known document in this case, so will be fast.
If you need views across multiple profiles though, your main document should probably be the favorite. You'll need to set up the right indexes, but performance shouldn't be a problem.
Actually, the permissions you describe don't add that much complexity to an EAV schema - as long as attributes can have multiple values the permissions list is just one more attribute.