I can't believe some of what is said by people on both sides of the NoSQL arguments. Discounting use of RDF data stores, almost all of my recent work involves PostgreSQL and MongoDB. I think that it is blatantly obvious which to use in specific circumstances. I have not had to do this yet, but using Datamapper.setup, you can integrate the use of both in the same application by storing some model data in a relational database and some in MongoDB, as it makes sense to do so.
I Can't Wait for NoSQL to Die
31–40 of 80 posts
Re: I Can't Wait for NoSQL to Die
#32Macs are better than Pc, C# is better than Java, Unix is better than Windows, RDBMS are better than NoSQL databases...
Why can't people just use the best tool for the job and move on...
From a personal stand-point we've switched from MySQL to Google AppEngine (and BigTable). Although I find there are some major drawbacks (e.g. joining tables) not having to worry about database servers and scalability is a major advantage. That said, if MySQL becomes the best tool for a particular feature, then let it be...
Re: I Can't Wait for NoSQL to Die
#33I can't believe some of what is said by people on both sides of the NoSQL arguments. Discounting use of RDF data stores, almost all of my recent work involves PostgreSQL and MongoDB. I think that it is blatantly obvious which to use in specific circumstances. I have not had to do this yet, but using Datamapper.setup, you can integrate the use of both in the same application by storing some model data in a relational…
Here is an article on mixing Datamapper + MongoDB + MySQL: http://lunarlogicpolska.com/blog/2010/02/15/mysql-and-mongod...
Re: I Can't Wait for NoSQL to Die
#34The scalability aspect of "NoSQL" is interesting, but I think possibly the more interesting part is the wide diversity of data models (key value, schema-less tables, document databases, etc)
True, some of these models are more restrictive than traditional RDBMSs to provide scalability, but I think some of them will often be useful even if scalability isn't initially a concern.
In fact the term "NoSQL" itself is more relevant to the data models than the scalability.
Re: I Can't Wait for NoSQL to Die
#35Earlier quoted context omitted.
Speaking as a member of the rails core team, if you heard someone say that then he made it up. Rails until 3.0 was heavily invested into SQL simply because it's what everyone used. However, it was swimming against the stream in that rails declared DBs to be something which is incrementally developed by the software through migrations instead of setup by DBAs per change tickets. This has been enormously successfully,…
this is simply because most high volume sites don't use these things anyways because they get very hard to scale later on. If you start with the assumption that "you don't need a DBA" then that's probably true. Just to give you an idea of my background, I work on a system using a commercial RDBMS that "scales" to thousands of commits/sec and tens of terabytes of data. We expect to take it to tens of thousands of comm…
I think that the message wasn't "app database-agnosticism", but "framework database-agnoticism".
Re: I Can't Wait for NoSQL to Die
#36Ted's point may be valid for BigTable-like databases. (I'm not saying it is, but I don't know enough about those to say so.) Those are designed for scalability and if you don't need the scalability you probably should use a RDBMS instead. But there are other advantages of SQL-less databases that don't deal with scale. I deployed my first MongoDB app a couple weeks ago. Even though it was a small (~1 developer month)…
I got downvoted awfully last night for trying to say this, but I'll say it again to back you up: Developing with mongodb is _lightning fast_ and holds up very very well. If you end up with problems, switch to SQL later! I don't think a lot of these people hating on the nosql projects have actually tried building something with them.
Why is it faster?
Re: I Can't Wait for NoSQL to Die
#37I myself am not actually sold on the noSQL movement, at least not on the idea of ditching SQL entirely. It has its place, but may not be the best solution for every problem.
That said, on the authors complaint about having to restart cassandra when doing the equivalent of an alter table: lately every time we do an alter table in MySQL (which takes hours on large tables, during which time you can do nothing with them), when the alter finally finishes, MySQL mysteriously crashes. MySQL may have given more thought to the problem, but their solution obviously has problems too.
Re: I Can't Wait for NoSQL to Die
#38Earlier quoted context omitted.
I got downvoted awfully last night for trying to say this, but I'll say it again to back you up: Developing with mongodb is _lightning fast_ and holds up very very well. If you end up with problems, switch to SQL later! I don't think a lot of these people hating on the nosql projects have actually tried building something with them.
I dunno... I find the combination of the Django ORM and South (in particular the --auto flag for auto-creating migrations) is incredibly productive. With the ORM, I can conjure up a query that answers pretty much any question I might have of my data. I've experimented with MongoDB (and a bunch with Redis) and I find I'm much more likely to end up with a query that I can't resolve without having to do a bunch of extra…
I've found that relational ORMs force me to write convoluted and weird code for all but the simplest of joins. Maybe django's ORM is better; I've mostly used SQLAlchemy and a few others.
Re: I Can't Wait for NoSQL to Die
#39Earlier quoted context omitted.
I got downvoted awfully last night for trying to say this, but I'll say it again to back you up: Developing with mongodb is _lightning fast_ and holds up very very well. If you end up with problems, switch to SQL later! I don't think a lot of these people hating on the nosql projects have actually tried building something with them.
Why is it faster?
It doesn't force you to fit non-tabular (eg. hierarchical) data into a table structure.
Also, no schema means the data structure is more malleable. With the right ORM, this fits in well nicely with polymorphism: I can store objects with some common features in the same collection, but when I retrieve them from the database I get different types of objects which inherit the same base object. mongoengine is one ORM that does this.
Re: I Can't Wait for NoSQL to Die
#40Earlier quoted context omitted.
"Sometimes you just want to store data on the disk in a safe and language agnostic way." You mean, kind of like a file?
Filesystem is the original document store. Unfortunately, most filesystems really suffer when you put $LOTS of files in the same folder, so you end up implementing a nested folder structure and that complicates your code. Now, if this is more complex than running an entire "object" store depends on the application. Also, the filesystem's addressing may not be granular enough (and so waste a lot of space,) if you are…
You should check out vertexdb. It's designed to be used just like a filesystem, but it fixes the shortcomings of filesystems when they are used as dbs.
http://github.com/stevedekorte/vertexdb
In production use at http://stylous.com