The different field types for the same named field I didn’t take into account. That would throw a wrench into it if one table wanted facets on a field but the other just wanted text searching on the same field name for example.
Guess without context the question becomes more difficult to answer, such as is it one client for all the tables, or one each, or…. Why even use a rdbms if there is no r in it in the first place? On Sun, Apr 10, 2022 at 7:51 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 4/10/2022 2:31 PM, Neha Gupta wrote: > > I want to query these tables differently in Solr as they don't have > > any relation between them. Could you please tell whether i should > > create different cores for each table or should i indexed them in one > > core with different entities. If latter is the case then how i can > > query Solr on basis of entity? > > I'm going to disagree with Saurabh Sharma here. > > If there truly is no relationship between the data in those tables, then > I would index them as separate cores, or collections if running in cloud > mode. The configurations will be cleaner, and there is much less chance > of a change in one table causing general problems for a combined core > ... those effects would be limited to the core for the table that is > changing. > > If you can use the same fields for data coming from multiple tables, > there is a certain amount of space savings that can be realized by > having one index instead of four, due to the way that Lucene file > formats work. For most setups, that space savings will be very small > compared to the problems that you can avoid by not combining the data. > > The only time it makes sense to have the data from multiple database > tables in the same core is when there is a definite relationship between > the tables. If you use JOIN queries on the DB server on a regular > basis, and that extends to searching as well, performance in Solr will > be better if Solr does not have to do a JOIN to accomplish its work. > The cross-core join capability in Solr is fairly limited and is NOT what > someone familiar with database joins would expect, particularly in the > arena of performance. > > As mentioned by Dave, if you do combine the data, you will want to have > at least one field indexed that can filter results as you need them > filtered. > > Thanks, > Shawn > >
