(I'm using types in a relational sense, not in the old elasticsearch "multiple types in an index" sense)
I have a typical relational data model with several types in a hierarchy. For illustration sake, let's call this an online book seller tracking publishers, authors and books:
| publisher | 1---* | author | 1---* | book |
Each publisher has many author who in turn have many book. In reality there are more layers of the hierarchy but this will suffice.
I need to run queries against each type where the query has to handle fields for the type and its parents: for the book query, I need to be able to search e.g. book.title, author.name and/or publisher.name. For the author query I might need to search publisher.name or author.name.
My initial plan was to create one index per type with all the columns that I need to query:
book index: book, author and publisher columns
author index: author and publisher columns.
publisher index: just publisher columns
That feels like it will get complicated, as any time a publisher changes, I'd have to update publisher, author and book indexes.
Finally the question: Is it reasonable to maintain only one of these indexes that holds ALL the data (so I suppose just the book index) and then use it for queries about author or publisher, even when they have completely independent of book? e.g. I might query authors by location without referencing or caring about what books they wrote.