3 ms·

Mongo and other nosql databases are still the absolute fastest way to get started particularly you don't know what your data is eventually going to look like.

jayd16 6y ago
Changing SQL schema is honestly just not that hard... but even still, you can always use json columns in postgres if you don't want the db to enforce a schema.
- vosper 6y ago
  Agreed, I've never understood this. There are lots of good migrations tools around for SQL databases. If people mean "you don't need to run migrations with Mongo, you can just start adding fields to documents as they're accessed, and clean up as-needed" then... don't do that. That's how the Mongo DB I am responsible for was managed for most of the last 10 years. It's a nightmare now, we can barely change it at all.
- offtop5 6y ago
  If your just prototyping you don't need a schema. Complaining mongo doesn't scale is like saying your Mita can't off-road
  - Scarbutt 6y ago
    If you are prototyping a local file will do, or store json in a text field in sqlite, or in a json column in postgres. You will even have more flexibility than mongo since you will not have the constraint of their document data model.
    - offtop5 6y ago
      Only your last option will allow me to send a webpage link to a friend for him to try it. The idea is if you have just a couple of days to crack out of MVP you don't want to waste time with postgres or whatever. The problem ends up being then your boss is like, all right this works keep going with it
      - setr 6y ago
        I don't understand why postgres w/ json enables a website, where sqlite and text files don't. You just ship the sqlite/text file with the rest of the webserver code? It's less work than setting up mongo, postgres, or whatever long-running data store. Just deploy the web application... and you're done.
        offtop5 6y ago
        So that would make sense, if it's purely for show. For a recent project we actually used firebase but I wanted to enable myself to update the database without redeploying the website. I generally dislike when people try to write off a technology just because they don't know how to use it. Don't hammer in screws, but it doesn't mean you should throw out all of your hammers
      - deleted 6y ago
        [deleted]
    - 35fbe7d3d5b9 6y ago
      Echoing this. My prototyping always starts with DB = {} at the top of my file. Sometimes it grows to serializing to disk / loading the dumped object from disk. Often times it's all I need to know that my idea was crap and needs revised. And it always keeps me from faffing about with infrastructure.
  - jayd16 6y ago
    >If your just prototyping you don't need a schema. Oh you always have a schema. Its just about whether you want to enforce it or not.
    - nucleardog 6y ago
      It’s enforced regardless in most situations. The question is whether you want it enforced on write with the database throwing an error, or enforced on every read by your app crashing or behaving incorrectly when it gets wildly unexpected values back.
- yawnxyz 6y ago
  yeah json columns are a game changer and will definitely "disrupt" nosql usage, at least for my own projects
adwww 6y ago
This is what the company I work for claimed. Now we are 10 years old and have a monster of a relational database stored in MongoDB. There's never a good moment to switch database, but there is always a new problem caused by storing relational data in a document store.
ogre_codes 6y ago
Before PostgreSQL added BSON support this may have been true, but now it's pretty easy to build an SQL database that you can extend arbitrarily just like with Mongo. You probably shouldn't use that too much, not for anything remotely production, but it's there if you need that flexibility or an easy place to dump javascript objects. When you are just getting started, it's super easy to manipulate SQL data structures regardless.
setr 6y ago
I disagree -- an RDBMS is pretty much safe/sane for any design, though it may not be the fastest. NoSQL databases (specifically, eventually consistent DBs) are only safe/sane in specific scenarios. If you don't know what your needs are, you should always start with an RDBMS -- it's not that difficult to go "up" to a NoSQL db from there (you're only losing information, and if you can't safely move because of loss of ACID... you'd probably have been really fucked if you started off without it), but you can't easily migrate back "down" to the RDBMS -- a NoSQL database stores almost no information about your data or its constraints. And your application will almost always want transactional guarantees and to model relationships properly -- generally only small chunks of the design (design-wise; data-wise it might be 90% of the app) can be treated with eventual consistency and have real scaling needs, which you can shift over to your nosql system. Apps are generally just metadata tracking with a dash of real work.
- yawnxyz 6y ago
  as a UX designer / product engineer, it's easier for me to jump into a nosql than to wire up a postgres instance for a small proof of concept project that I know won't really go anywhere
  - nucleardog 6y ago
    sqlite? All my proof of concept (and some production) stuff just uses that until I need features or concurrency that it can’t provide.
  - ndiscussion 6y ago
    Sorry, this might come off as obtuse, I don't mean it that way. Perhaps I'm misreading your title, but I find it odd that a UX designer or product person would be the one writing proofs of concept that require a database. Unless you mean for solo projects? In that case, it may work for you, but if you're not a database expert, it makes sense you would work around your limitations. That doesn't necessarily mean it's a best practice.
35fbe7d3d5b9 6y ago
Careful here: while this may be true of some NoSQL stores that I've not used, this is a tarpit for the wide column datastores I'm familiar with (Dynamo, Cassandra, and others). It's very easy to get going quickly and find out that you've tripped over antipatterns, and now your database is "a database, a Ruby app, and 30ms of latency on every call". It's easy to think "I'll model this later" and end up hitting the database five times in a row to answer a question. With these systems, up front modeling of your data model and access patterns is essential if the trade off you are trying to make (far less functionality for smooth performance at ridiculous scale) will ever make sense.

jayd16 6y ago

Changing SQL schema is honestly just not that hard... but even still, you can always use json columns in postgres if you don't want the db to enforce a schema.

vosper 6y ago
Agreed, I've never understood this. There are lots of good migrations tools around for SQL databases. If people mean "you don't need to run migrations with Mongo, you can just start adding fields to documents as they're accessed, and clean up as-needed" then... don't do that. That's how the Mongo DB I am responsible for was managed for most of the last 10 years. It's a nightmare now, we can barely change it at all.
offtop5 6y ago
If your just prototyping you don't need a schema. Complaining mongo doesn't scale is like saying your Mita can't off-road
- Scarbutt 6y ago
  If you are prototyping a local file will do, or store json in a text field in sqlite, or in a json column in postgres. You will even have more flexibility than mongo since you will not have the constraint of their document data model.
  - offtop5 6y ago
    Only your last option will allow me to send a webpage link to a friend for him to try it. The idea is if you have just a couple of days to crack out of MVP you don't want to waste time with postgres or whatever. The problem ends up being then your boss is like, all right this works keep going with it
    - setr 6y ago
      I don't understand why postgres w/ json enables a website, where sqlite and text files don't. You just ship the sqlite/text file with the rest of the webserver code? It's less work than setting up mongo, postgres, or whatever long-running data store. Just deploy the web application... and you're done.
      - offtop5 6y ago
        So that would make sense, if it's purely for show. For a recent project we actually used firebase but I wanted to enable myself to update the database without redeploying the website. I generally dislike when people try to write off a technology just because they don't know how to use it. Don't hammer in screws, but it doesn't mean you should throw out all of your hammers
    - deleted 6y ago
      [deleted]
  - 35fbe7d3d5b9 6y ago
    Echoing this. My prototyping always starts with DB = {} at the top of my file. Sometimes it grows to serializing to disk / loading the dumped object from disk. Often times it's all I need to know that my idea was crap and needs revised. And it always keeps me from faffing about with infrastructure.
- jayd16 6y ago
  >If your just prototyping you don't need a schema. Oh you always have a schema. Its just about whether you want to enforce it or not.
  - nucleardog 6y ago
    It’s enforced regardless in most situations. The question is whether you want it enforced on write with the database throwing an error, or enforced on every read by your app crashing or behaving incorrectly when it gets wildly unexpected values back.
yawnxyz 6y ago
yeah json columns are a game changer and will definitely "disrupt" nosql usage, at least for my own projects

adwww 6y ago

This is what the company I work for claimed. Now we are 10 years old and have a monster of a relational database stored in MongoDB. There's never a good moment to switch database, but there is always a new problem caused by storing relational data in a document store.

ogre_codes 6y ago

Before PostgreSQL added BSON support this may have been true, but now it's pretty easy to build an SQL database that you can extend arbitrarily just like with Mongo. You probably shouldn't use that too much, not for anything remotely production, but it's there if you need that flexibility or an easy place to dump javascript objects. When you are just getting started, it's super easy to manipulate SQL data structures regardless.

setr 6y ago

I disagree -- an RDBMS is pretty much safe/sane for any design, though it may not be the fastest. NoSQL databases (specifically, eventually consistent DBs) are only safe/sane in specific scenarios. If you don't know what your needs are, you should always start with an RDBMS -- it's not that difficult to go "up" to a NoSQL db from there (you're only losing information, and if you can't safely move because of loss of ACID... you'd probably have been really fucked if you started off without it), but you can't easily migrate back "down" to the RDBMS -- a NoSQL database stores almost no information about your data or its constraints. And your application will almost always want transactional guarantees and to model relationships properly -- generally only small chunks of the design (design-wise; data-wise it might be 90% of the app) can be treated with eventual consistency and have real scaling needs, which you can shift over to your nosql system. Apps are generally just metadata tracking with a dash of real work.

yawnxyz 6y ago
as a UX designer / product engineer, it's easier for me to jump into a nosql than to wire up a postgres instance for a small proof of concept project that I know won't really go anywhere
- nucleardog 6y ago
  sqlite? All my proof of concept (and some production) stuff just uses that until I need features or concurrency that it can’t provide.
- ndiscussion 6y ago
  Sorry, this might come off as obtuse, I don't mean it that way. Perhaps I'm misreading your title, but I find it odd that a UX designer or product person would be the one writing proofs of concept that require a database. Unless you mean for solo projects? In that case, it may work for you, but if you're not a database expert, it makes sense you would work around your limitations. That doesn't necessarily mean it's a best practice.

35fbe7d3d5b9 6y ago

Careful here: while this may be true of some NoSQL stores that I've not used, this is a tarpit for the wide column datastores I'm familiar with (Dynamo, Cassandra, and others). It's very easy to get going quickly and find out that you've tripped over antipatterns, and now your database is "a database, a Ruby app, and 30ms of latency on every call". It's easy to think "I'll model this later" and end up hitting the database five times in a row to answer a question. With these systems, up front modeling of your data model and access patterns is essential if the trade off you are trying to make (far less functionality for smooth performance at ridiculous scale) will ever make sense.