@ehsansh consider using a “join” table that stores an ID of the user and the ID of the article. This way you can have unlimited number of articles without running into the 16MB limit. Although if you are only storing IDs then 16MB could store a lot of them. An ID is 24 hex chars long. 1000 IDs is still only 24k chars. Depending on your case case you may have different kind of performance problems depending on which path you take
@ehsansh Yet again, if you are planning to store a lot of data in one object and keep updating it on every purchase then I would suggest you to create a separate document. You can go with the first approach only if you are confident enough that your data won't exceed the 16MB block limit.
Also... Mongoose is a ORM used to make your job easier for creating DB and writing queries.
@panigrah Thanks a lot. I store ids in an array and number of articles that user could choose and number of articles that he has chosen. So I have one array fields and 2 or 3 fields that contain a number. It shouldn't be more than the limit. But it seems safer to have two collections. What is difference of performance between those two approaches?
I have another question I have different categories of articles. like physics, math,etc. Which approach is better?To have specific schema for each category? or to have one schema for all categories but have one category field inside the schema? Coding for the second approach is simpler but how is the performance in these two ways? Which is faster and better?
@ehsansh I would say the purpose of using mongoose is simple interface. I understand that mongoDB has native elements to complete the job done but mongoose provides a lot more functionalities to add on and great support from the community.
It all depends on your datasets. If you think your data will grow infinitely in a single object, then you have to create a separate collection for that same. If not, its your call. @ehsansh
I am not sure about the performance delay in case of fetching data from various collections. It shouldn't differ a lot I am thinking. If it was bad in its performance, then mongo wouldn't have had that feature at all. If they are letting you use it, then I suppose they would have configured it accordingly.
@ehsansh I do not know which one would be better from a performance point of view. My guess is that unless you are expecting the number of documents to get to 100s of thousands the difference may not be material. Also mongo will let you switch from one schema to another - so you can take either path now and then convert if you have performance problems later.
@ehsansh for your second question it comes down to what your use case is and how the categories differ. If it is only about categorization of an article then I would only have one Article schema for all categories and a field in the Article that points to the correct category.