5 ms·
Ask HN: How do you use a database when prototyping a web application?
I wonder how other HN users approach data storage when iterating on a web application product early in its development. Please share your approach here.
To elaborate on the question in the title:
* Do you use a "traditional" SQL database like Postgres or MySQL and deal with schema migrations from the start? Do you keep your data denormalized (e.g., as JSON in Postgres) until a certain point in the development process?
* Do you use a NoSQL database like Mongo? If so, do you then keep it or do you migrate to SQL?
* Do you go with a BaaS?
* Do you avoid a database altogether and store your data as flat files?
- hardwaresofton 11y agotldr; I use a nosql db because you don't need to worry about schema which should give you an initial iteration speed boost, but the database type should be decided based on the data. In the SQL case, you should decide on a migration technology sooner rather than later. Either way, keep good schema documentation (if it's not already in code). DISCLAIMER: I'm highly partial to rethinkdb (http://rethinkdb.com/ http://rethinkdb.com/), though I think I have good reasons - Since I find document stores a little easier to setup/work with (especially when they have nice convenient web UIs built in) I've often started with those. The obvious benefit is letting your schema change while you prototype the application. You could easily do this also with JSON in Postgres obviously, but I find the web interface/ease of use that databases like rethinkdb (http://rethinkdb.com/ http://rethinkdb.com/) offer to be refreshing. - When you decide what database you should use in production, it should be based on the data. Note that most document stores are not actually "schema-less", it's just up to you to properly interact with the tens of schemas that are true at any one point in time. A sane set up will often have the schema documented somewhere. I find myself writing documentation in files like SCHEMA.md (sometimes in it's own folder with a file for each actual model/collection), if I use a NoSQL database. If you find that a relational model fits your data best (if your data is highly relational, and very inter-connected -- a lot can be said about when you should use a relational db vs a non-relational one), then I would still suggest documenting your schema, and picking a migration strategy BEFORE you start. Find what technology you're going to use to migrate your database, and start using it from day 1. - If you you are rapidly prototyping, it might slow you down to add a BaaS. At least I've found that it's really easy for me to download the binary for a database I want to use, run the binary, connect to it in code. - Many frameworks start you out with using an on-disk SQLite database (django, rails). If you mean like an actual flat text file, it really depends on the guarantees you want out of your database. If you are writing a highly functionally-minded app, and know that you are going to essentially keep a append-only log of what's happening, a flat file might be all you need (and of course, you'll need some locking if you want to do more than one thing at a time to the file)