Thanks. That is good option. But typically, the child will have parent id stored via routing. So if we need to use child record for lookup, then we will need to add the parent id as separate attribute into child record. But we will need to make sure that this attribute name does not conflict with parent record.
Currently, we have 1 to 1, parent child mapping. Child attribute updates are more frequent. But parent attribute updates have many variants. So we had separated out them into parent and child so that indexing can happen independently, irrespective of transaction type.
Now using enrich feature, I am trying to create a flatter index, where I am trying to populate both parent and child on parent record, irrespective of whether indexing is coming for parent record or child record. That will allow me to get rid of few complex has child queries. Will give this a shot. Thank you!