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.
Related
I'm using Firestore to build a social app modeled after Facebook. I see lots of posts that resemble Twitter with the followed/followers approach, but that doesn't feel like a great fit for an app that uses friends.
My data model would have a top-level collection ("posts") and each post would have the poster's user ID ("UserID"). To build the timeline, I'm thinking of simply using the new-ish 'in' query:
var timelineQuery = postsRef
.where('UserID', whereIn: [user_123, user_456])
.orderBy('timestamp');
'in' queries are limited to an array size of 10, but my app is pretty specialized, so my average user will likely only have a couple of friends even if I get 1M+ users. For my rare user that has 40 or 50 friends, I could run this query 4 or 5 times, with the more active friends in the first query and updating the timeline as subsequent results come in.
Is this a reasonable approach? I don't see any examples using it, so am guessing I'm missing something?
Yup, this sounds like a reasonable approach.
The common alternative is to invert the data model, by building an explicit "wall" for each user in the database. So in that scenario you'd find all a user's followers when they post, and then write the new post to the "wall" of each follower. This makes writing more complex and slower, but makes reads a lot simpler and very scalable.
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 am working on an application which will have users.. who create posts.. and other users can like/comment on any post.
I am trying to figure out a best way to design db tables for this. I have read the anypics tutorial on parse.com site. They keep all comments and likes in a table called "Activity". (which makes sense) being able to query any type of activity (like/comment) from a separate table without having to touch "posts" table.
My question is- in this scenario how do I fetch all posts that current user created along with likes and comments on each those posts?
Anypic app by parse makes a separate request to fetch number of likes on each post (which I think is not ideal.) I am new to nosql data stores.. so if someone could help me out with suggestion on how to structure data that would be great.
Also, how bad is it to store all likes/comments as an array in the post itself? I think this won't scale but I might be wrong.
Thanks
In terms of Parse, I would use an afterSave Cloud Function to update the Post anytime a like/comment is added.
Have a look at the documentation here, in the most simple case you just create an afterSave for the Activity class that increments the like/comment count.
In a more advanced scenario you might want to handle update/delete too. E.g. if someone can change their 'like' to 'not like' you would need to look at the before/after value and increase/decrease the counter as needed.
I am a fan of storing extra 'redundant' data, and no-sql/document-db systems work well for that. This is based on the idea that writes are done infrequently compared to the number of reads, so doing some extra work during/after the write has less impact and makes the app work more smoothly.
I'm making a blog in which the home page shows all the blog posts each linking to the post's separate page. I am using sinatra as the framework and mongo as the backend. The url's that I generate are something like this:
http://blogera.io/prakhar/post/4fb8c0562767621088000002/hello-world
The long number being the ObjectID of the post as stored in mongo. On reaching the url I'll extract the object id, query the db and display the post. Is there a better way to do this? The url's dont look very good and it might be bad for SEO as well?
Any thoughts / suggestions would be great. Thanks!
I would use a number as identifier, not MongoDB's internal _id value of a document. That would make your URLs a lot cleaner, such as:
http://blogera.io/prakhar/post/1/hello-world
In this case, you would query MongoDB for the blog post with that numerical identifier.
It's also better in case you decide to change database in the future. You rarely wish to change the structure of your URLs. If you do, you would have these long identifiers in your URLs that just stem from your use of MongoDB in the past. That just doesn't make sense.
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)