We really still need to know more about your use case. In particular what types of questions will you be asking of the data? It's useful to do this in plain english without mapping to any specific implementation.
Joel Bernstein http://joelsolr.blogspot.com/ On Fri, Apr 29, 2016 at 9:43 AM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > You do not structure Solr to represent your database. You structure it > to represent what you will search. > > In your case, it sounds like you want to return 'user-records', in > which case you will index the related information all together. Yes, > you will possibly need to recreate the multiple documents when you > update one record (or one user). And yes, you will have the same > information multiple times. But you can used index-only values or > docvalues to reduce storage and duplication. > > You may also want to have Solr return only the relevant IDs from the > search and you recreate the m-to-m object structure from the database. > Then, you don't need to store much at all, just index. > > Basically, don't think about your database as much when deciding Solr > structure. It does not map one-to-one. > > Regards, > Alex. > ---- > Newsletter and resources for Solr beginners and intermediates: > http://www.solr-start.com/ > > > On 29 April 2016 at 20:48, Sandeep Mestry <sanmes...@gmail.com> wrote: > > Hi All, > > > > Hope the day is going on well for you. > > > > This question has been asked before, but I couldn't find answer to my > > specific request. I have many to many relationship and the mapping table > > has additional columns. Whats the best way I can model this into solr > > entity? > > > > For example: a user has many recordings and a recording belongs to many > > users. But each user-recording has additional feature like type, number > etc. > > I'd like to fetch recordings for the user. If the user adds/ updates/ > > deletes a recording then that should be reflected in the search. > > > > I have 2 options: > > 1) to create user entity, recording entity and user_recording entity > > - this is good but it's like treating solr like rdbms which i mostly > avoid.. > > > > 2) user entity containing all the recordings information and each > recording > > containing user information > > - this has impact on index size but the fetch and manipulation will be > > faster. > > > > Any guidance will be good.. > > > > Thanks, > > Sandeep >
