Don't know how useful this diagram is, but this would be the basic structure of the database:
Basically, each user would have multiple records(which could go into tens of thousands range), and each of those records would have 3 metadata records, say title, description, and tags.
Most of the operations would be write operations. All of the data would be validated by the backend before being added to the database. Some Googling has led me to believe that a relational database like Postgres or MySQL would make much more sense for my use case[1]. Is that correct, or is Mongo relevant for my use case?
When evaluating whether mongoDB would be a good fit for the use case
you really want to ask yourself NOT "what data do I have" but "what
questions do I have" or "what do I need to do in the application"?
Depending on the types of reads and writes you will be performing,
MongoDB could be an excellent solution for your application or it
could be a poor solution. I don't think we have enough information to
say either way.
you really want to ask yourself NOT "what data do I have" but "what
questions do I have" or "what do I need to do in the application"?
Depending on the types of reads and writes you will be performing,
MongoDB could be an excellent solution for your application or it
could be a poor solution. I don't think we have enough information to
say either way.
I guess a good example of the type of application I'm trying to build would be Pocket.
I don't have much experience working with databases, but from a few example applications I've seen, it seems to me that Mongo would fit my scenario well.
For instance, Meteor.js, which runs on Mongo, has a todo list example app which is pretty similar to the type of reads and writes I will be performing.
I hope this information is enough to evaluate whether Mongo would be a good fit.
I think MongoDB could be an excellent fit here - it's easy to structure the data you would be reading and writing - and it naturally fits into probably two collections: users and "things" (as in things they saved to read later). Each "thing" would have a reference to the user, the date it was saved in addition to already mentioned title, description, and an array of tags. The important thing for you would be to understand how to index the data for efficient updates and queries.
This is the perfect case where you will use MongoDB, key value, in a bson (json like) file. here is your schema:
Thanks for the help, aliane.
User : {
textRecordA:{
[
textRecord1A:{data},
textRecord2A:{data},
textRecord3A:{data},
]
},
textRecordB:{
[
textRecord1B:{data},
textRecord2B:{data},
textRecord3B:{data},
]
},
textRecordC:{
[
textRecord1C:{data},
textRecord2C:{data},
textRecord3C:{data},
]
},
}
I think maybe you missed the part where in the original post it was said that
"user would have multiple records(which could go into tens of thousands range)"
Your suggested schema would not work well at all.
We have exactly this structure on our mongo based 3d printing news site microfabricator.com
There is a collection of users with a "username" primary key which is unique. There is also a collection of posts which have as one of thier fields the username, in most cases we just display the posts without reference to the user document, the username is suffient to display thier identity and avatar. unless somebody wants to do something with the author, like send them a message, or look at thier profile. Viewing all the posts by username is also easy.
Thanks for the help Asya, glad to know that MongoDB would be a good fit for my use case.
I think MongoDB could be an excellent fit here - it's easy to structure the data you would be reading and writing - and it naturally fits into probably two collections: users and "things" (as in things they saved to read later). Each "thing" would have a reference to the user, the date it was saved in addition to already mentioned title, description, and an array of tags. The important thing for you would be to understand how to index the data for efficient updates and queries.AsyaTo view this discussion on the web visithttps://groups.google.com/d/msgid/mongodb-user/c8cb9c04-4536 -4f17-8196-7bc0a9da0057%40goog legroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks for the help, aliane.
This is the perfect case where you will use MongoDB, key value, in a bson (json like) file. here is your schema:User : {textRecordA:{[textRecord1A:{data},textRecord2A:{data},textRecord3A:{data},]},textRecordB:{[textRecord1B:{data},textRecord2B:{data},textRecord3B:{data},]},textRecordC:{[textRecord1C:{data},textRecord2C:{data},textRecord3C:{data},]},}I am building an application, and I am not sure whether it would make sense to use MongoDB. The application would be write-heavy.Don't know how useful this diagram is, but this would be the basic structure of the database:Basically, each user would have multiple records(which could go into tens of thousands range), and each of those records would have 3 metadata records, say title, description, and tags. Most of the operations would be write operations. All of the data would be validated by the backend before being added to the database. Some Googling has led me to believe that a relational database like Postgres or MySQL would make much more sense for my use case[1]. Is that correct, or is Mongo relevant for my use case?
Thanks Tim, its good to know that people are using MongoDB in a similar scenario for production sites.
We have exactly this structure on our mongo based 3d printing news site microfabricator.comThere is a collection of users with a "username" primary key which is unique. There is also a collection of posts which have as one of thier fields the username, in most cases we just display the posts without reference to the user document, the username is suffient to display thier identity and avatar. unless somebody wants to do something with the author, like send them a message, or look at thier profile. Viewing all the posts by username is also easy.On Nov 3, 2014 10:41 AM, "Asya Kamsky" <as...@mongodb.com> wrote:I think maybe you missed the part where in the original post it was said that"user would have multiple records(which could go into tens of thousands range)"Your suggested schema would not work well at all.AsyaThis is the perfect case where you will use MongoDB, key value, in a bson (json like) file. here is your schema:User : {textRecordA:{[textRecord1A:{data},textRecord2A:{data},textRecord3A:{data},]},textRecordB:{[textRecord1B:{data},textRecord2B:{data},textRecord3B:{data},]},textRecordC:{[textRecord1C:{data},textRecord2C:{data},textRecord3C:{data},]},}I am building an application, and I am not sure whether it would make sense to use MongoDB. The application would be write-heavy.Don't know how useful this diagram is, but this would be the basic structure of the database:Basically, each user would have multiple records(which could go into tens of thousands range), and each of those records would have 3 metadata records, say title, description, and tags.Most of the operations would be write operations. All of the data would be validated by the backend before being added to the database. Some Googling has led me to believe that a relational database like Postgres or MySQL would make much more sense for my use case[1]. Is that correct, or is Mongo relevant for my use case?
댓글 없음:
댓글 쓰기