3 ms·
While I like PG, I think this is such a specific use-case. And in general I've learned to avoid JSON columns in databases. I was doing some large data aggregat
by dimgl 5y ago
While I like PG, I think this is such a specific use-case. And in general I've learned to avoid JSON columns in databases.
I was doing some large data aggregation using PG and I was pretty disappointed with its performance. I didn't think about trying MySQL...
- mst 5y agoIn general, I agree, though pg's JSONB is effectiuvely hstore2 so its performance is surprisingly good. This example didn't involve a JSON column in the database at all though, I was talking about turning native database rows into json data - so given tables like users(id, name) and posts(post_id, author_id, title, body) (apologies for pseudocodish rendering) instead of <author_id>, <author_name>, <post_id_1>, <post_title_1>, <post_body_1>, <author_id>, <author_name>, <post_id_2>, <post_title_2>, <post_body_2>, you'd instead get <author_id>, <author_name>, json[ { post_id: <post_id_1>, title: <post_title_1>, body: <post_body_1> }, { post_id: <post_id_2>, title: <post_title_2>, body: <post_body_2> } ] so on the application side you'd just deal with (for each row) something like let id = author.id; let name = author.name; let posts = author.posts; and the 'posts' variable would be an array of objects with 'post_id', 'title' and 'body' keys.