Says I'm building a blog system. So for a blog post, the user will be able to write text and upload media file. Here's the flow behind :
an insert query is created when user click new post.
with that id it can save the blog content, both text and uploaded media.
the problem with this approach is many empty table record have to be deleted to optimize my db. I need to use this approach as I'm using nosql db (mongodb), so the media files' name have to have blog post id as references.
Most database drivers for MongoDB allow you to generate ObjectIDs on the client-side. If you set the _id field of a document to such a generated ObjectID, MongoDB will use it instead of one generated on the database. This allows you to create a group of referencing documents on the application-side and then insert them all at once.
However, it might be more appropriate in your use-case to embed all the sub-documents in the blog-post-document and store it all in the database as one document.
Related
I need to have a page with common settings for my web-app, and using mongodb as my database.
I am planning to just create this collection with only one document. it will always have one document.
Is there a way to create one document by default in some way? and then just edit it from UI?
Or I should create one document from UI itself and then keep editing it?
If I use config file then user won't have flexibility of changing the value as they need.
Please share if you have better suggestion.
You can certainly have a collection with a single document in it.
Is there a way to create one document by default in some way?
You can insert the document with default values, if there isn't already a document in the collection, when your application starts.
I've been chugging along building my mongodb but I just realised I haven't actually taken the time to think of the best strategy for that and I might be misusing the nosql structure and building a more traditional relational structure. I'm building a community forum and so far the collections I have are as follows:
User - stores all user settings/data such as email, name, password, date joined, email/notification preferences, etc..
Profile - stores handle, gender, user location, forum rank, interests and then several arrays containing id's of things like an array of follower id's, array of post ids, array of upload id's, array of club id's, array of posts the user has liked, etc.
Posts - stores comment data, creator user id, category and then has an array of id's to uploaded files and an array of user id's for likes.
Uploads - GridFS schema to use when uploading files
What I'm now realising that all these arrays of id's of things in other collections are behaving a lot more like a relational db, especially the Profile schema which is basically just a collection of id's to other collections. Can you give any advise on the type of db I'm creating and how to improve it? For example, should I have a single User schema which contains all posts and profile data directly inside it rather than storing id's to a separate schema in a different collection? As I'm using this project to learn, I'd really like to continue using mongodb rather than moving to something like MySQL.
As Akrion eluded too in the comment above, the first step was to combine the User and Profile schemas. The other thing that I wasn't thinking about before was what information gets called together. The new UserProfile schema shouldn't contain things like comments/posts/uploads/likes as those things will be better off existing as part of the Post document. My problem was thinking that having a record of those things in my UserProfile would optimise the retrieval of those items when I needed them but I just ended up bloating my UserProfile schema. It's no different searching the posts collection by creator rather than by an ID taken from the UserProfile document. The Upload documents are now no longer GridFS schemas but are instead records of files in the file system but that is less relevant to my original question.
I am a newbie to nosql world and I am stuck during the designing of my database.I am developing an app where there are two collections,
User
Leave
When a user applies for leave ,leave details will be added to leave collection and the leaveID(Mongo generated) will be added to the user collection depending on which user applied for leave.
Now my question is for adding the _id to the user collection ,Should i write one more query or is there any way to auto fill the user collection when a document is added to the leave Collection. ie should i write 2 queries to insert into the leave and user collection or with only one query the task could be completed.
I am using java driver for interacting with db.
In mongodb, with that collection structure, you'll have two use two requests, yes. One for inserting leave, another for inserting leave reference to a user document.
You could do with one request if your leaves were embedded in a user, but that might not make sense, according to your other requirements.
I am wondering how I can update an embedded document (in the MongoDB term) in an one-to-many relationship. For example, a blog can have many comments and those comments are embedded in a blog document. In the Java development space, shall I do remove a comment is going to be edited and insert an edited version of the comment back to the collection data type, a list, and call the save method in Spring Data MongoDB (that is the update method in MongoDB) since I can't identify the comment without a ID field? This question is based on an assumption that an embedded document doesn't come with a ID by design.
I'm new to mongoDB and trying to figure out what would be the best way to store user logs. I identified two main solutions, but can't figure out which might be the best. If others come to mind, please feel free to share them ;)
1)The first is about storing a log in all the collections that I have. For instance, If I have the 'post', 'friends', 'sports' and 'music' collections, then I could create a log field in each document in each collection with all the logging info that I want to store.
2)The second way is to create an entire 'log' collection, each document having a type ('post', 'friends' ...) to identify the kind of log I'm storing along with the id of the document that is refered to.
What I really need is to be able to store and retrieve data (that is, everything but logs) as fast as possible. (so if I go with (1), I would have to always remove the logs from my selection queries since they would be useless most of the time)
Logs will only be accessed periodicaly (for reporting and stats mostly), yet will require to be mapped to their initial document (in case of (2)).
I will be creating logs for almost all the non log data to store (so storing logs inside each collection might be faster : one insert vs two).
Logging could also be done asynchronously to ease the load on the server.
With all that in mind, I can't really manage to find which is the best for my needs. Would anyone have any idea / comments to share ?
Thanks a lot !
How you want to access your logs will play a big part in your design decision. By what criteria will you access your log documents? Will you have to query by type (e.g. post, friends) AND id (object id of the document)? Is there some other identifying feature? This can be extra overhead as you would have to read your 'type' collection first, get the id you're after, then query your logs collection. This creates a lot more read overhead.
What I would recommend is a separate logs collection as this keeps all related data in the one place. Then, for each log document, have a 1:1 mapping between document ids for your type collections, and your log collection. e.g. If you have a friend document, use the friend document's _id field as the _id field for your document in your logs collection. That way you can directly look up your log document without a second read. If you will have multiple log records for each type document, use an array in the log document and append each log record to it using mongo's $push. This would be a very efficient log architecture in terms of storage, write ($push requires no read - 'set and forget') and lookup time (smart 1:1 mapping - no more than one query needed if you have the _id).