5 ms·

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.

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.