3 ms·

Another reason to choose MongoDB is built-in array and nested dict support, with good enough indexing. So you don't have to create bullshit m2m tables with ted

by est 13y ago

Another reason to choose MongoDB is built-in array and nested dict support, with good enough indexing. So you don't have to create bullshit m2m tables with tedious joins for a fucking tagging system

mwhite 13y ago
Obligatory JSON and hstore in Postgres comment.
- est 13y ago
  stable version, every value is string. No atomic incremental operations, no nesting, shitty index.
  - mwhite 13y ago
    JSON has non-string values and nesting. [1] I read somewhere that nesting in hstore is coming in the next version (Q3 2014?) and non-string types are on deck. Compared to the nightmarish development workflows and processes I've had to deal with resulting from using CouchDB as a main datastore, having to get the entire JSON value in order to update one key seems like not that big of a deal. What NoSQL databases even let you do incremental operations in that sense? Shitty index? It seems like you should be able to make an index on a value inside the JSON just as easily as any other index. Then maybe some advanced features of Postgres can really shine: http://www.postgresql.org/docs/8.3/static/indexes-bitmap-scans.html http://www.postgresql.org/docs/8.3/static/indexes-bitmap-sca... https://wiki.postgresql.org/wiki/Index-only_scans https://wiki.postgresql.org/wiki/Index-only_scans I'm also exploring a solution for abstracting that as a normal, non-JSON table for semi-structured data using views. Basically, it seems like for semi-structured data where you know what the schema is, but maybe it just changes over time or isn't 100% certain, so it's not possible to store it using a typical schema, JSON + indexes + views offers the best of both worlds. [1] http://clarkdave.net/2013/06/what-can-you-do-with-postgresql-and-json/ http://clarkdave.net/2013/06/what-can-you-do-with-postgresql...

3 ms·

Another reason to choose MongoDB is built-in array and nested dict support, with good enough indexing. So you don't have to create bullshit m2m tables with ted

by est 13y ago

Another reason to choose MongoDB is built-in array and nested dict support, with good enough indexing. So you don't have to create bullshit m2m tables with tedious joins for a fucking tagging system

mwhite 13y ago
Obligatory JSON and hstore in Postgres comment.
- est 13y ago
  stable version, every value is string. No atomic incremental operations, no nesting, shitty index.
  - mwhite 13y ago
    JSON has non-string values and nesting. [1] I read somewhere that nesting in hstore is coming in the next version (Q3 2014?) and non-string types are on deck. Compared to the nightmarish development workflows and processes I've had to deal with resulting from using CouchDB as a main datastore, having to get the entire JSON value in order to update one key seems like not that big of a deal. What NoSQL databases even let you do incremental operations in that sense? Shitty index? It seems like you should be able to make an index on a value inside the JSON just as easily as any other index. Then maybe some advanced features of Postgres can really shine: http://www.postgresql.org/docs/8.3/static/indexes-bitmap-scans.html http://www.postgresql.org/docs/8.3/static/indexes-bitmap-sca... https://wiki.postgresql.org/wiki/Index-only_scans https://wiki.postgresql.org/wiki/Index-only_scans I'm also exploring a solution for abstracting that as a normal, non-JSON table for semi-structured data using views. Basically, it seems like for semi-structured data where you know what the schema is, but maybe it just changes over time or isn't 100% certain, so it's not possible to store it using a typical schema, JSON + indexes + views offers the best of both worlds. [1] http://clarkdave.net/2013/06/what-can-you-do-with-postgresql-and-json/ http://clarkdave.net/2013/06/what-can-you-do-with-postgresql...