поиск с использованием свободного nHibernate с использованием LINQ, где свойство может находиться в многочисленных местах в производных классах

Question

У меня есть структура классов следующим образом (псевдокод):

CompanyName (id, name) // Other information about the company  

IUsefulSearchField // A field that can appear at any depth in the below
IUsefulSearchField2 // A field that can appear at any depth in the below

BaseClass (id) // Some other values needed in class & This class will be inherited by everything below

Class1: BaseClass (IUsefulSearchField, CompanyName) // Extra values not in the search

Class2: BaseClass (IUsefulSearchField, IList<CompanyName>, IUsefulSearchField2) // Extra values not in the search

Class3: BaseClass (CompanyName, IUsefulSearchField2)

Class4: BaseClass (IList<IUsefulSearchField>)

Вышеприведенное повторяется с несколькими разбросанными полями поиска (они не могут содержаться в базовом классе, так как в подклассе может быть одно или несколько)

Мне нужно выполнить поиск в этих общих полях и названиях компаний, мне также нужно ограничить 1 или многие производные типы, например, (Псевдокод)

SELECT Object.ID, Object.Type, Object.CompanyName, Object.UsefulSearchField1,  
null AS Object.UsefuleSearchField2 
FROM Class1 UNION ALL  (SELECT Object.ID, Object.Type, Object.CompanyName, 
Object.UsefulSearchField1,  Object.UsefuleSearchField2 
FROM Class2 Inner Join IList<RelationshipToGet Companies> ) etc…. 

WHERE Object.Type in ('Class1', 'Class2', 'Class4') AND CompanyName Like 'Peps%' 
AND (UsefulSearchField1 = 'Bond' OR UsefulSearchField1 IS NULL) AND 
(UsefulSearchField2 > 1000 OR UsefulSearchField2 IS NULL)

Таблицы будут содержать + 10 м строк в каждой, так что есть достаточное количество данных для прохождения

У меня такой вопрос: должен ли я создать денормализованное индексированное представление и коррелированный поисковый объект, к которому я обращаюсь, возвращая тип объекта и идентификатор, чтобы я мог перестроить объект, когда пользователь нажимает кнопку редактирования в результатах поиска - ИЛИ - Должен ли я установить интерфейс для каждого объекта, который создает отдельные части запроса LINQ - мы в настоящее время делаем это, и он оказывается очень медленным, поскольку представляется возможным оптимизировать его так, чтобы поиск выполнялся только по имеющимся терминам ( т.е. если выбран только Class1, другие классы не нужно запрашивать)

Большое спасибо, что нашли время, чтобы прочитать, добавится, если потребуется больше информации

Answer 1

Зависит от вашей готовности вести поиск объектов. С точки зрения производительности наилучшим вариантом является индексированное представление, и любой администратор БД рекомендует это решение. Однако Lucene.net был портирован с Java, чтобы удовлетворить хотя бы некоторые ваши требования. Есть несколько серий блогов о люцене, а tekpub имеет целый эпизод о поиске .

Лично я не использовал NHibernate Search для чего-то продвинутого, поэтому я не уверен, что он полностью удовлетворит ваши требования. Возможно, стоит взглянуть на это. Если вы хотите мою рекомендацию, то индексированное представление. Это чертовски быстро, чтобы начать работать!

РЕДАКТИРОВАТЬ: Я бы выбрал либо совершенно новый QueryOver API или Criteria. Вы наверняка столкнетесь с некоторыми ограничениями, если будете использовать провайдера «NHibernate Contrib» Linq. Это только на 80% совместимость, но вы можете делать удивительные вещи с Criteria и QueryOver. Если вы читаете пост ayendes, вы можете легко преобразовать его в QueryOver для некоторой проверки времени компиляции вместо магических строк, если это вас беспокоит.

Answer 2

Будьте очень осторожны с провайдером nHibernate LINQ v1 - ограниченной поддержкой Join и множеством ошибок - поддерживается множество операций LINQ.Мы ожидаем перехода на nHIbernate v3 с переписанным LINQ, использующим деревья выражений.Просто предупреждение приятель.