3 ms·
There is a place for document store, and in my opinion it's for prototyping in a domain one's not necessarily experienced with yet. In that situation, trying to
by boomzilla 12y ago
There is a place for document store, and in my opinion it's for prototyping in a domain one's not necessarily experienced with yet. In that situation, trying to come up with the perfect (or just reasonably good enough) data model is overwhelming. So it's easier and faster to just go ahead with a document store. I like Solr because I know it best and Apache licensed and I'll likely need a search engine later. Postgres JSON type, Elastic search, Mongo or others are perfectly valid choices too.
However, once the app has shaped up, I make it a priority to harden up the data model and move the core data set to a relational database (Postgres is the likely choice now). One nice thing with this migration is I can do a lot of clean up and normalization with the originally unstructured data set.
- oacgnol 12y agoI think this is the most reasonable take I've read and encompasses the whole "right tool for the job" mindset that I like. I've found that when starting a new project I get paralyzed with coming up with the perfect data model that will also scale in the future, so I'd rather punt, take the tradeoffs that come with schemaless DBs, and keep a plan to migrate to something like Postgres in the backlog. Holding on to our tools too tightly is IMO how projects get crippled.
- StavrosK 12y agoExactly that, but I would also add that migrating things that are documents off to a document database (or leaving them there after prototyping) is perfectly fine.