Mongodb – how to query nested json objects in mongodb

Alright, so you seem to want to create a graph from a join tree. That's a pretty natural thing to want to do.

It's not as easy as it should be in Pg, mainly because of the lack of support for column-aliases in the record pseudo-type.

Here's what I came up with:

SELECT row_to_json(r, true)
FROM (
    SELECT
        d.id,   
        d.name, 
        json_agg(c_row) AS components
    FROM devices d
    INNER JOIN device_components dc ON (dc.deviceid = d.id)
    INNER JOIN (
        SELECT  
            c.id,       
            c.name,     
            json_agg(m) AS manufacturers
        FROM components c
        INNER JOIN component_manufacturers cm ON (cm.componentid = c.id) 
        INNER JOIN manufacturers m ON (cm.manufacturerid = m.id) 
        GROUP BY c.id 
    ) c_row ON (c_row.id = dc.componentid)
    GROUP BY d.id
) r(id, name, component);

The general idea here is, at every level of object nesting where you're producing an array of objects, use json_agg in a group_by. The json_agg function implicitly calls row_to_json to transform a rowtype into json. In the SELECT clause specify aliases for the synthetic columns so the json key names are correct when the row is fed into the outer level.

As the outer level isn't aggregated, use row_to_json over a subquery instead of using json_agg. If you want a single json result instead of a set of json rows, you can change row_to_json to json_agg in the outer level.

I've only tested on 9.3, as that's what I have installed and sqlfiddle seems to be having some issues.

Update: Unfortunately json_agg doesn't exist on 9.2, it was added in 9.3. However, this is a simple enough case that you can just use array_agg instead, so this should work in 9.2:

SELECT row_to_json(r, true)
FROM (
    SELECT
        d.id,   
        d.name, 
        array_agg(c_row) AS components
    FROM devices d
    INNER JOIN device_components dc ON (dc.deviceid = d.id)
    INNER JOIN (
        SELECT  
            c.id,       
            c.name,     
            array_agg(m) AS manufacturers
        FROM components c
        INNER JOIN component_manufacturers cm ON (cm.componentid = c.id) 
        INNER JOIN manufacturers m ON (cm.manufacturerid = m.id) 
        GROUP BY c.id 
    ) c_row ON (c_row.id = dc.componentid)
    GROUP BY d.id
) r(id, name, component);

Ideally PostgreSQL would support this sort of query more naturally, without the subqueries, but I think we'd need a new join type, or at least some functions to use with lateral queries. It all plans out into a civilised query plan anyway (though it'd be better with suitable indexes):

                                                                QUERY PLAN                                                                
------------------------------------------------------------------------------------------------------------------------------------------
 Subquery Scan on r  (cost=1050.26..1282.94 rows=720 width=106)
   ->  GroupAggregate  (cost=1050.26..1273.94 rows=720 width=188)
         ->  Merge Join  (cost=1050.26..1226.42 rows=7704 width=188)
               Merge Cond: (d.id = dc.deviceid)
               ->  Index Scan using devices_pkey on devices d  (cost=0.15..58.95 rows=720 width=82)
               ->  Sort  (cost=1050.11..1069.37 rows=7704 width=110)
                     Sort Key: dc.deviceid
                     ->  Merge Join  (cost=403.16..552.77 rows=7704 width=110)
                           Merge Cond: (c_row.id = dc.componentid)
                           ->  Subquery Scan on c_row  (cost=253.38..285.63 rows=720 width=110)
                                 ->  GroupAggregate  (cost=253.38..278.43 rows=720 width=286)
                                       ->  Sort  (cost=253.38..258.73 rows=2140 width=286)
                                             Sort Key: c.id
                                             ->  Hash Join  (cost=44.75..135.00 rows=2140 width=286)
                                                   Hash Cond: (cm.manufacturerid = m.id)
                                                   ->  Hash Join  (cost=26.20..87.03 rows=2140 width=86)
                                                         Hash Cond: (cm.componentid = c.id)
                                                         ->  Seq Scan on component_manufacturers cm  (cost=0.00..31.40 rows=2140 width=8)
                                                         ->  Hash  (cost=17.20..17.20 rows=720 width=82)
                                                               ->  Seq Scan on components c  (cost=0.00..17.20 rows=720 width=82)
                                                   ->  Hash  (cost=13.80..13.80 rows=380 width=208)
                                                         ->  Seq Scan on manufacturers m  (cost=0.00..13.80 rows=380 width=208)
                           ->  Sort  (cost=149.78..155.13 rows=2140 width=8)
                                 Sort Key: dc.componentid
                                 ->  Seq Scan on device_components dc  (cost=0.00..31.40 rows=2140 width=8)
(25 rows)

As with most things, it depends.

First of all, if you're not 100% certain that the data will always be valid JSON, use a normal text type instead.

If the data is indeed always JSON, I would use a JSON type if for no other reason that as documentation that the column contains JSON data.

If there will ever be any chance of requiring indexing of data, go for the JSONB datatype. If insert performance is critical, choose JSON (or even a text type) instead. The JSON datatype stores the JSON data as-is, while the JSONB datatype removes empty nodes and whitespace and even duplicate keys (the last one is kept). This means that JSONB is storing less data, but requires minor reconstruction on retrieval.

For all other cases, I would go with JSONB as the "best" generic JSON type in PostgreSQL at present, and this is also the recommendation in the documentation. See http://www.postgresql.org/docs/9.4/static/datatype-json.html