3 ms·

Actually, when you have a toy project that needs a RDBMS, go ahead and use SQLite. The consensus is that relatively few applications are a good fit for MongoDB

by rch 10y ago

Actually, when you have a toy project that needs a RDBMS, go ahead and use SQLite. The consensus is that relatively few applications are a good fit for MongoDB, irrespective of scale.

tensor 10y ago
And for those few where you think MongoDB might be a good fit, you should probably use something like RethinkDB instead.
honkhonkpants 10y ago
Or leveldb for those even more trivial storage needs.
- deleted 10y ago
  [deleted]
3pt14159 10y ago
Why? Now I have to learn a crappier version of SQL (no support for real date types, no user management, etc) and heaven help me if my toy project actual gets traction. I'll have to migrate everything over to Postgres or I'll have to keep my DB on a single server because it's just a single file. Compared to just using Postgres or even MySQL I do not understand the benefit. It takes less than an hour to spin up a PG database with user permissions and migrations to make tables and indexes.
- rch 10y ago
  SQLite provides date and time functions for working with e.g. ISO8601 strings, but I understand where you're coming from. https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/datatype3.html#section_2_2 https://www.sqlite.org/datatype3.html#section_2_2
alexchantavy 10y ago
What's an example of an application that is a good fit for MongoDB?
- kolme 10y ago
  I actually don't have any experience, but I heard this from wise people: If you have a file store service, where you're storing relatively big files (big images, videos, etc) and some metadata associated to them which need to be queried. It's easier to implement than "traditional" solutions (metadata goes in a RDBMS and actual files go to some directory, NAS, or whatever). Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Like I said, I didn't tried this myself so take it with a grain of salt. Also, I don't know how that compares to storing blobs in a RDBMS.
  - KMag 10y ago
    > Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Sharding file storage is pretty easy. On the other hand, I'm not familiar with the MongoDB APIs, but I assume it doesn't support handing a socket file descriptor from the webserver over to MongoDB so Mongo can sendfile(2) the data directly from the kernel's page cache to the TCP socket for locally resident data. With the files stored directly on disk and metadata in an RDBMS, your webserver can sendfile(2) those files that are permanently stored locally or cached to local disk, and act as a proxy for other shards. Extra context switches and coping your data one or two times more than necessary can add up quickly.
- breischl 10y ago
  If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column." eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense. Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy. Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.

by rch 10y ago

Actually, when you have a toy project that needs a RDBMS, go ahead and use SQLite. The consensus is that relatively few applications are a good fit for MongoDB, irrespective of scale.

tensor 10y ago

And for those few where you think MongoDB might be a good fit, you should probably use something like RethinkDB instead.

honkhonkpants 10y ago

Or leveldb for those even more trivial storage needs.

deleted 10y ago
[deleted]

3pt14159 10y ago

Why? Now I have to learn a crappier version of SQL (no support for real date types, no user management, etc) and heaven help me if my toy project actual gets traction. I'll have to migrate everything over to Postgres or I'll have to keep my DB on a single server because it's just a single file. Compared to just using Postgres or even MySQL I do not understand the benefit. It takes less than an hour to spin up a PG database with user permissions and migrations to make tables and indexes.

rch 10y ago
SQLite provides date and time functions for working with e.g. ISO8601 strings, but I understand where you're coming from. https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/datatype3.html#section_2_2 https://www.sqlite.org/datatype3.html#section_2_2

alexchantavy 10y ago

What's an example of an application that is a good fit for MongoDB?

kolme 10y ago
I actually don't have any experience, but I heard this from wise people: If you have a file store service, where you're storing relatively big files (big images, videos, etc) and some metadata associated to them which need to be queried. It's easier to implement than "traditional" solutions (metadata goes in a RDBMS and actual files go to some directory, NAS, or whatever). Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Like I said, I didn't tried this myself so take it with a grain of salt. Also, I don't know how that compares to storing blobs in a RDBMS.
- KMag 10y ago
  > Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Sharding file storage is pretty easy. On the other hand, I'm not familiar with the MongoDB APIs, but I assume it doesn't support handing a socket file descriptor from the webserver over to MongoDB so Mongo can sendfile(2) the data directly from the kernel's page cache to the TCP socket for locally resident data. With the files stored directly on disk and metadata in an RDBMS, your webserver can sendfile(2) those files that are permanently stored locally or cached to local disk, and act as a proxy for other shards. Extra context switches and coping your data one or two times more than necessary can add up quickly.
breischl 10y ago
If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column." eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense. Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy. Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.