5 ms·

I find them useful in many scenarios: - Bootstrap projects with open or changing requirements. A relational model is usually harder to maintain. - Storing and

by fauria 10y ago

I find them useful in many scenarios: - Bootstrap projects with open or changing requirements. A relational model is usually harder to maintain. - Storing and querying objects with complex structures, such as those received from APIs. - Having a single programming language across your entire application stack (ie MEAN). Sometimes comes up as a "should" or even a "must" requirement. - Fast and simple object storage (ie sessions).

kuschku 10y ago
> - Storing and querying objects with complex structures, such as those received from APIs. > - Fast and simple object storage (ie sessions). Those would also be fulfilled by using a jsonb column in Postgres, right?
- fauria 10y ago
  For storage and retrieval I think it can probably be used pretty much the same way. For querying, my guess is that frameworks such as MongoDB's Aggregation (https://docs.mongodb.com/manual/aggregation https://docs.mongodb.com/manual/aggregation) are more versatile.
  - kuschku 10y ago
    Well, postgres can do all that what that site said, too If you have a table with a column data in format json or jsonb, you can do a SELECT data->>cust_id AS cust_id, SUM(data->>amount) WHERE data->>status = 'A' GROUP BY data->>cust_id; just as well in postgres. Or, for the third example, SELECT DISTINCT data->>cust_id; (See https://www.postgresql.org/docs/9.5/static/functions-json.html https://www.postgresql.org/docs/9.5/static/functions-json.ht... )
- alani0991 10y ago
  >Those would also be fulfilled by using a jsonb column in Postgres, right? Storing JSON is now natively supported in MySQL 5.7
  - kuschku 10y ago
    It’s less about storing JSON, more about querying it. Look at my answer to the sibling comment for an example.
  - gaius 10y ago
    Right, the point being that there is no need to choose between key-value and relational DB - since Postgres et al do it all. Which makes the so-called "noSQL" approach completely obsolete.
- s_kilk 10y ago
  Shameless plug: my personal project, BedquiltDB (https://bedquiltdb.github.io https://bedquiltdb.github.io) provides a mongo-alike nosql api on top of PostgreSQL jsonb functionality. Why choose when you can have both? ;)

by fauria 10y ago

kuschku 10y ago

> - Storing and querying objects with complex structures, such as those received from APIs. > - Fast and simple object storage (ie sessions). Those would also be fulfilled by using a jsonb column in Postgres, right?

fauria 10y ago
For storage and retrieval I think it can probably be used pretty much the same way. For querying, my guess is that frameworks such as MongoDB's Aggregation (https://docs.mongodb.com/manual/aggregation https://docs.mongodb.com/manual/aggregation) are more versatile.
- kuschku 10y ago
  Well, postgres can do all that what that site said, too If you have a table with a column data in format json or jsonb, you can do a SELECT data->>cust_id AS cust_id, SUM(data->>amount) WHERE data->>status = 'A' GROUP BY data->>cust_id; just as well in postgres. Or, for the third example, SELECT DISTINCT data->>cust_id; (See https://www.postgresql.org/docs/9.5/static/functions-json.html https://www.postgresql.org/docs/9.5/static/functions-json.ht... )
alani0991 10y ago
>Those would also be fulfilled by using a jsonb column in Postgres, right? Storing JSON is now natively supported in MySQL 5.7
- kuschku 10y ago
  It’s less about storing JSON, more about querying it. Look at my answer to the sibling comment for an example.
- gaius 10y ago
  Right, the point being that there is no need to choose between key-value and relational DB - since Postgres et al do it all. Which makes the so-called "noSQL" approach completely obsolete.
s_kilk 10y ago
Shameless plug: my personal project, BedquiltDB (https://bedquiltdb.github.io https://bedquiltdb.github.io) provides a mongo-alike nosql api on top of PostgreSQL jsonb functionality. Why choose when you can have both? ;)