Предполагая, что вы собираетесь принимать результаты Solr и представлять их через другое приложение, я бы сделал наименьший элемент - Titles - модель для документов, что облегчит представление, где появится результат. Выполнение этого способа сводит к минимуму количество кода приложения, которое необходимо написать. Если ваши пользователи обращаются к Solr напрямую, я могу вместо этого использовать страницу в качестве моего документа - предположительно, вы используете Solr's highlighting feature, чтобы помочь своим пользователям определить, как их поисковый запрос (ы) совпадают.
Для правоустанавливающих документов я бы моделировать схему следующим образом:
- Книга ID + Номер страницы + Заглавие [строка - уникальный ключ]
- Книга ID [целое]
- Название книги [лексемы текст поле]
- Номер страница [TrieIntField]
- название [лексемы текстовое поле]
- Содержимое для этой комбинации книги/название/страницы [лексемы т ext field]
Могут быть другие атрибуты, которые вы хотите захватить, такие как автор, дата публикации, издатель, но вы не объясните выше, какую другую информацию у вас есть, поэтому я оставляю это в этом примере.
Текстуальные запросы могут затем включать Book Name, Title и Content, где вы можете определить одно поле, что индексируется, но не сохраняется, что служит в качестве мишени для <copyField/> деклараций в вашем schema.xml, чтобы обеспечить легкий поиск по всем три в то же время.
Для индексации, не зная больше об индексируемых данных, я бы использовал ICU Tokenizer и Snowball Porter Stemming Filter со спецификацией языка в текстовых полях для обработки неанглийских данных - при условии, что все книги находятся на одном языке. И если английский, стандартный токенизатор вместо ICU.
Заполните описание для каждого стола и то, что вы планируете искать в Solr. – orangepips
@orangepips Это просто, книга имеет много страниц, а затем страница имеет много названий. – SaidbakR