4 ms·

I think that one of the reasons that MongoDB is getting traction is that many people don't use relational databases in a relational way for many projects. Lots

I think that one of the reasons that MongoDB is getting traction is that many people don't use relational databases in a relational way for many projects. Lots of data just isn't as relational as we hope it would be and also people are terrible at modeling data in a relational way. Relational databases were designed around the idea of minimizing storage footprint, and we have nearly infinite storage capacity relative to many databases, so many devs don't care about only having one copy of a piece of data in the DB. Also, SQL is great as a data retrieval language, but it is awful for inputting data. Yes, it works, but writing data to MongoDB in general has felt more natural than generating SQL to shotgun in data. You could argue that ORM's solve a lot of the uglyness of inputting data into a DB and I agree with you, but you still have to deal with table migrations and being able to just add a field in your code and not have to go hold the database's hand or write a migration to make it work is incredibly convenient. In the end, MongoDB solves a lot of convenience issues for programs that don't need relational data or programmers who don't want to use an ORM, create SQL strings, or write migrations to get their database to store their data. It's not for everybody, but if it fits your needs, it solves some problems much more conveniently than MySQL.

IgorPartola 15y ago
I agree with your first comment: a lot of people suck at creating models that are relational. It's also difficult to use relational data outside of a relational system: when you retrieve it from your RDBMS and get it as, say, a Python dictionary. This is the big problem with using SQL for the web. However, I disagree with your other statements: (1) we do not have infinite storage. Most data stores keep everything in RAM, and that is pretty limited. (2) It's really easy to input data into SQL. There are in fact a bunch of methods to do so (almost all still rely on SQL). (3) (more of a comment, than disagreement) ORM's don't solve much. They just remove the need for engineering a data access API and trade it for performance and cleanliness of code.
- cdcarter 15y ago
  Lots of datastores don't keep everything in RAM though. CouchDB uses up a whole ton of disk, because disk is cheap and the way the database is structured the disk reads aren't even a problem for performance.
  - IgorPartola 15y ago
    Fair enough. I'm more familiar with Mongo and Redis.
    - mathias_10gen 15y ago
      MongoDB doesn't require everything in ram either.
ahi 15y ago
>also people are terrible at modeling data in a relational way. While true, I don't think this is quite fair. Not all of our clients/employers are huge entities with business processes and data requirements that are stable for decades. Many, if not most of the projects that come across the desk of an IT developer are temporary projects with indefinite scope. One of my current projects is modelling a rather complex set of intertwined business processes. Part of the problem is just getting the client to explain their existing processes completely. Another part of the problem is that the processes are always changing. As soon as I think I finally have all the data models figured out, there's one more tweak. I am not great at data modelling or SQL, but tweaking a dozen 50 line joins on a daily basis is not happy fun time for anyone. At some point the specced data model, the model as implemented, and the conceptual model that's in my head get out of sync in some mysterious way, the plot is lost and it all turns to shit. On top of this I'm also trying to manage an object model that sorta maybe corresponds to the data model. In cases where the spec changes frequently, the higher cognitive load of maintaining a decent relational model is simply not worth it.
rubinelli 15y ago
Minimizing storage footprint was important, but the main selling point was data integrity, or at least data consistency. In large organizations, databases are still the most common point of integration between applications, and even those that are only accessed by a single application tend to outlive them as requirements and technologies change.
St-Clock 15y ago
"Relational databases were designed around the idea of minimizing storage footprint, and we have nearly infinite storage capacity" Well, foreign keys are not just a way to minimize storage: it speeds up future updates. If you duplicate your data everywhere for faster read access, your write cost just increased.

IgorPartola 15y ago

I agree with your first comment: a lot of people suck at creating models that are relational. It's also difficult to use relational data outside of a relational system: when you retrieve it from your RDBMS and get it as, say, a Python dictionary. This is the big problem with using SQL for the web. However, I disagree with your other statements: (1) we do not have infinite storage. Most data stores keep everything in RAM, and that is pretty limited. (2) It's really easy to input data into SQL. There are in fact a bunch of methods to do so (almost all still rely on SQL). (3) (more of a comment, than disagreement) ORM's don't solve much. They just remove the need for engineering a data access API and trade it for performance and cleanliness of code.

cdcarter 15y ago
Lots of datastores don't keep everything in RAM though. CouchDB uses up a whole ton of disk, because disk is cheap and the way the database is structured the disk reads aren't even a problem for performance.
- IgorPartola 15y ago
  Fair enough. I'm more familiar with Mongo and Redis.
  - mathias_10gen 15y ago
    MongoDB doesn't require everything in ram either.

ahi 15y ago

>also people are terrible at modeling data in a relational way. While true, I don't think this is quite fair. Not all of our clients/employers are huge entities with business processes and data requirements that are stable for decades. Many, if not most of the projects that come across the desk of an IT developer are temporary projects with indefinite scope. One of my current projects is modelling a rather complex set of intertwined business processes. Part of the problem is just getting the client to explain their existing processes completely. Another part of the problem is that the processes are always changing. As soon as I think I finally have all the data models figured out, there's one more tweak. I am not great at data modelling or SQL, but tweaking a dozen 50 line joins on a daily basis is not happy fun time for anyone. At some point the specced data model, the model as implemented, and the conceptual model that's in my head get out of sync in some mysterious way, the plot is lost and it all turns to shit. On top of this I'm also trying to manage an object model that sorta maybe corresponds to the data model. In cases where the spec changes frequently, the higher cognitive load of maintaining a decent relational model is simply not worth it.

rubinelli 15y ago

Minimizing storage footprint was important, but the main selling point was data integrity, or at least data consistency. In large organizations, databases are still the most common point of integration between applications, and even those that are only accessed by a single application tend to outlive them as requirements and technologies change.

St-Clock 15y ago

"Relational databases were designed around the idea of minimizing storage footprint, and we have nearly infinite storage capacity" Well, foreign keys are not just a way to minimize storage: it speeds up future updates. If you duplicate your data everywhere for faster read access, your write cost just increased.