5 ms·
From what I've seen, the data model has a lot of utility as long as you don't need super high concurrent performance. Basically, the same area as where rails i
by jbooth 13y ago
From what I've seen, the data model has a lot of utility as long as you don't need super high concurrent performance. Basically, the same area as where rails is the right tool - we want easy features and rapid development, will worry about scaling later.
- yummyfajitas 13y agoWhat does mongodb offer above and beyond using postgres or redis for this use case?
- jbooth 13y agoI've barely used it, but the json document thing with a lot of random convenience functions in the query language seem to lend themselves well to rapid development. For postgres you'd be mapping to a relational schema, and for redis you'd be storing the json yourself as a blob, without any server-side manipulation capabilities (or using redis maps/sets/etc, which are awesome, but aren't as general as json). I haven't been doing very much web dev the last few years though so it's possible that my first impressions are wrong. I'm just repeating what I've been told, basically.
- deleted 13y ago[deleted]
- Sanddancer 13y agoPostgres has had a native json type and the latest version improves upon the functions given to manipulate json data. So data that may not map well to a relational schema can just be put in the json object type and handled accordingly. Also, because it's attached to an SQL engine, you can use things like views on your json data if it makes sense for the type of data you're querying. There has been a considerable amount of work put into postgres over the past few years for getting it to handle your data regardless of what it looks like. The developers seem to have a very good grasp on the fact that not all data is alike, and giving tools that will work well, and together with, all your data leads to a lot fewer headaches in the long run.
- mattdeboard 13y agoAbsolutely nothing.
- bkanber 13y agoMongo's really great for rapid prototyping. You don't need to worry about updating the schema at the db level, it can store any type of document in any collection without complaining, it's really easy to install and configure, the query language is simple and only takes a couple of minutes to learn, it's pretty fast in most use cases, it's pretty safe in most use cases, and it's easy to create a replica set once your prototype gets usage and starts scaling. Mongo does everything well up until you reach the level where you need heavy-hitting, at-scale, mission-critical performance and reliability. Most projects out there (99 in 100?) will never reach the level of scale that requires better tools than mongo. And since the rest of it is so easy to use, it makes mongo a great starting point. You can always switch databases later, but mongo gives you the flexibility to concentrate on more important things in the early stages of a project.
- MichaelGG 13y agoWhat does it offer over using Postgres (or others) with a JSON column? Or MS SQL with an XML column?
- bkanber 13y agoEase of use.
- deleted 13y ago[deleted]
- integraton 13y ago> You don't need to worry about updating the schema at the db level What's your magic non-db level, supposedly-easier-than-updating-a-schema approach to renaming a field common to all existing documents in a collection, eg, rename an "author" field to "writer"?
- dodyg 13y agoThis is where a nice query/manipulation language come handy http://www.rethinkdb.com/api/#js http://www.rethinkdb.com/api/#js