Эффективное внедрение фасетного поиска в реляционных базах данных
дополнение PInvoke.NET Меню для поиска предзаписанного кода P/Invoke. Намного легче, чем разработка маршалинга кодируют себя, особенно когда существуют противные объединения и требования выравнивания.
3 ответа
Я могу только подтвердить то, что говорит Нильс. РСУБД не подходят для многомерного поиска. Я работал с некоторыми умными решениями, счетчиками кеширования, использованием триггеров и т. Д. Но, в конце концов, внешний выделенный индексатор всегда выигрывает.
МОЖЕТ БЫТЬ, если вы преобразовываете свои данные в размерную модель и скармливаете ее некоторому OLAP [я имею в виду механизм MDX] - он будет работать хорошо. Но это кажется слишком сложным решением, и оно определенно не будет работать в реальном времени.
Напротив, решение с выделенным механизмом индексации (подумайте о Lucene, подумайте Sphinx ) можно сделать почти реальным. время с инкрементным обновлением индекса.
IMO, реляционные базы данных не так хороши для поиска. Вы получите лучшую производительность от специальной поисковой системы (например, Solr / Lucene).
Что касается счетчиков, зачем их извлекать через SQL? В любом случае вам придется перебирать набор результатов в коде, так почему бы не сделать там свой счет?
В настоящее время я использую этот подход в разрабатываемом мной приложении для фасетного поиска, и оно работает нормально. Единственная сложная часть - настроить код так, чтобы не выводить фасет, пока он не достигнет нового фасета. В это время выведите фасет и количество найденных для него строк.
Этот подход предполагает, что вы извлекаете список всех совпадающих элементов и, следовательно, несколько строк с одним и тем же аспектом. Если вы упорядочите этот результат по фасетам, то вместо этого легко получить счет в коде.