Why I'm So Happy About MongoDB
collaborable.com
collaborable.com
Of course constraints are tedious when you're in "experimentation" mode (to quote another post I see here) and are doing rapid, early development. But once you're in production with data that's critical/important (i.e., not someone's list of their favorite songs; more like, their bank statements and medical histories), constraints are the bees knees.
Once you have data constraints in place, now migrations are hard - whether or not you're on a SQL database. You need to either update all old documents to match new schemas, or open up your constraints to "expect both" (where by "both" I really mean, "any number of 18 different formats...oh make that 19") - and that is the potentially slippery slope here into a coding crapfest.
Disclaimer: I'm the author of a very popular SQL tool for Python (SQLAlchemy) as well as a new database migrations tool (Alembic).
Also great work on Alembic, I started using it a few weeks ago and am very pleased.
Some of the other constraints you'll have to implement in your software. The advantage: you don't put application logic outside of your application. The disadvantage: Every bit of code touching that value has to know the limitations. I wonder if this could be solved by using a message queue and just have dedicated step for updating/deleting data
See but now you're building some big thing. Let's just include that in MongoDB or whatever, a "constraints engine". So that you don't have to build it from scratch each time, and can have some mature, well tested thing instead of something ad-hoc and probably buggy. Now you need to carefully build migrations again !
A convention-based approach, or even a well thought out data-enforcement approach, will have bugs and failures, and you just have to hope these failures aren't severe enough that you lose your "one" chance.
Relational constraints OTOH when used in their usual way make it virtually impossible to have situations like this.
each version migration is a function that takes a record in an old state a migrates it to a new one.
once you read a record from the db that has an outdated version number you run all the pending migrations and then save.
with this scheme your application code only has to know how to deal with the latest schema version. all the rest is handled by migrations.
What's worse than migrations? Being unable to turn an application off, since it uses the old schema.
With ChronicDB we support indefinite backward compatibility. Unlike per-record versioning tricks, application code does not need to be aware of migration code.
Downvote away, but is it too much to ask to upvote meaningful blog posts that present something new?
(I'm a NoSQL OSS developer/contributor and enthusiast.)
The general consensus on this is to structure your data so that it encapsulates your business needs in one document structure (which is atomic on changes), but i find it hard to always conform to in the real world.
So now i have to use zookeeper (memcached also works) to setup global locks on those specific batch update actions. I guess it's a small price to pay right? Right?
See the following:
http://www.mongodb.org/display/DOCS/Server-side+Code+Executi... http://www.mongodb.org/display/DOCS/Server-side+Code+Executi...
Then, last week I was working with a 3rd party API and returned a big JSON response for their transactions. I wanted to store a lot of their response in a database and it looked like a huge pain. Searching around for the best ways to go about storing JSONs in MySQL I found the following comment (http://stackoverflow.com/questions/3564024/storing-data-in-m...):
"CouchDB and MySQL are two very different beasts. JSON is the native way to store stuff in CouchDB. In MySQL, the best you could do is store JSON data as text in a single field. This would entirely defeat the purpose of storing it in an RDBMS and would greatly complicate every database transaction.
Don't."
Wait, NoSQL systems' default store is JSON?!? A few clicks later and I was playing with Mongo over at https://mongolab.com/ ... installing the PHP Mongo extension was a piece of cake. I was up and running in minutes.
Now, instead of developing one or several tables to store the information from the 3rd party API, I just dump their JSON response right into a Mongo collection. I can query whatever I want from that ... and there might be information that I want later on, that I didn't realize to store initially. If I had created a regular MySQL table that info wouldn't be there, but with Mongo I'm storing everything, so I'll be able to use that other info later if I want.
I don't think that Mongo is a replacement for MySQL — they are too different tools with distinct advantages and disadvantages. But Mongo definitely suits certain applications better. So, use the tool that best suits your project!
It might not be exactly what you were looking for, but it could have the same outcome.
However, there are a couple planned features that'll change this. Virtual collections is one, but the other is the $ operator in field selection..which I believe is planned for 2.1.
Even as-is though, they are useful. The tag example is simplistic...let me give you a real case from mogade.com. We have a scores collection, which looks something like:
{
_id: ObjectId('...'),
leaderboard: ObjectId('...'),
user: 'leto',
daily: {
points: 100,
data: 'level 10',
date: ....,
},
weekly: {
points: 150,
data: 'level 8',
date: ....,
},
overall: {
points: 300,
data: 'level 15',
date: ....,
}
}
Also, I wrote about collections vs embedded documents: http://mongly.com/Multiple-Collections-Versus-Embedded-Docum...
Edit: I wouldn't rely on the age of a feature request as a sign that there's something fundamentally wrong with a design. Not everything can be top priority.