как структурировать данные для поиска

Question

Я пишу поисковое приложение специально для музыкальных плейлистов.

Жанр и формат файла отличаются от списка воспроизведения к списку воспроизведения, и иногда в списке воспроизведения также есть различия. Существует также концепция «синонимичных» тегов (например, городской будет охватывать как хип-хоп, так и R & B, но не наоборот).

Ниже приведен список поисковых запросов и ожидаемых результатов.

Евангелие: должно вернуть все плейлисты хотя бы с одной евангельской песней. Сначала будут показаны плейлисты со всеми евангельскими песнями. Городские: должны вернуть все R & B и хип-хоп. снова плейлисты со всеми городскими треками будут на первом месте. хип-хоп: должен вернуть все хип-хоп, но не r & b. flac: должен возвращать все списки воспроизведения, которые содержат файлы flac. начиная с тех, которые являются чистыми flac. Хип-хоп флак: сначала должен вернуть хип-хоп флаки, а затем другой хип-хоп аудио хип-хоп и флак: должны возвращать только хип-хоп флаки хип-хоп аудио: должен возвращать хип-хоп флаки, хип-хоп mp3-файлы и т. д.

Поскольку я только начинаю этот проект, я думаю о лучшем способе проиндексировать все это. Будет ли здесь полезен полнотекстовый поиск, такой как Lucene? Примечание. У меня нет текста, описывающего эти списки воспроизведения, но я мог бы сгенерировать его.

Я подумываю организовать все эти термины как «теги» и сохранить их в базе данных «многие ко многим».

таблица: список воспроизведения (pk (id), desc) таблица: тег (pk (id), desc) таблица: playlist_has_tag (pk (link_id, tag_id))

Чтобы решить городской == хип-хоп || Я хотел бы добавить таблицу tag_synonyms:

таблица: tag_synonyms (pk (tag_id, synonym_tag_id))

Тогда у меня было бы две записи, указывающие, что город включает в себя хип-хоп и рнб: городской идентификатор тэга, тэг хип-хопа идентификатор городского, идентификатор тега rnb

Я чувствую, что при таком подходе запрос может быть достаточно запутанным.

Может ли CouchDB быть здесь полезен? В настоящее время я использую PostgreSQL. Есть ли какое-нибудь программное обеспечение, которое облегчит подобные вещи?

Я бы хотел иметь возможность в будущем развернуть и поддержать сложные условия поиска, например:

(хип-хоп или дом) И тип файла: mp3 И обложка: нет

А также включать такие вещи, как продолжительность и т. Д.

Answer 1

Если вы попытаетесь слишком серьезно задуматься о том, как структурировать данные для поиска, есть большая вероятность, что вы пропустите важный поиск, который вы действительно могли бы использовать в своем приложении.

В качестве альтернативы (и это из опыта) вы заканчиваете тем, что заново изобретаете все виды методов индексации.

У меня есть некоторый опыт работы с lucene (есть версия java и .net, был порт C, но я не уверен, насколько он жив в наши дни) - и он может делать удивительные вещи с данными, которые хранятся в любой структуре .

Мне нравится внешний вид couch db, все зависит от того, насколько сильно вы хотите поэкспериментировать с чем-то новым и мощным или пойти на что-то, что (в настоящее время) довольно закалено: люцен.

Answer 2

Полнотекстовый индекс будет вам полезен, если ваши пользователи будут определять запросы. Просто создайте пользовательское текстовое поле, которое описывает каждый атрибут, который вы хотите найти, например, "городской тип файла: PDF Евангелие" и поиск.

Answer 3

ОК, просто мозговой штурм здесь -

Возможно использование восьмеричного или двоичного кода для хранения ваших типов "формата" в качестве битовой маски?

http://www.nitrogen.za.org/viewtutorial.asp?id=17

RandB: 1 HipHop: 2 Евангелие: 4 Городской: 8

Теперь эти вещи аддитивны. Вы знаете, что если что-то помечено как Urban, вы не собираетесь хранить «8» в поле флага, но вы будете хранить 11 ... Urban && HipHop && RandB. Это всего лишь часть «бизнес-аналитики», которую вам придется где-то прописать.

Затем вы можете использовать двоичные сравнения, чтобы выяснить, какие флаги вы ищете.

Answer 4

Я не понимаю, как программное обеспечение базы данных будет играть роль в вашем решении.

Если бы я был тем, кто это реализует, я бы сначала обеспечил, чтобы все связанные данные были собраны в обычном порядке. Это включает в себя такие вещи, как категории, произведения искусства, тексты песен и т. Д.

Основным преимуществом этого является то, что ваша идея «сложных» поисков на самом деле становится довольно простой.