Попробую словами, без кода, объяснить свою проблему.
Есть бизнес — объект, называемый Order. Каждый его экземпляр хранится в строке таблицы Orders.
В нем около 150 полей, значительная часть (около половины) из которых — это id элементов справочников (перечислений).
Чтобы сделать объект "доступным для отображения" есть View, которая называется OrdersView.
Исторически сложилось, что в самом начале в объекте было гораздо меньше полей,
потом новые поля добавлялись в объект, в таблицу(как NULLable поля) и во View (как LEFT OUTER JOIN).
И по всему этому хозяйству надо делать всякие сложные поиски, которые формулируются в терминах полей,
которые выдает View.
Со временем, по мере увеличения кол-ва полей, кол-ва справочников и кол-ва записей в таблицу Orders —
поиск работал все более медленно. В попытках ускорить его я попытался построить индексы по полям View.
И столкнулся с тем, что для View, использующего Left Outer Join — это невозможно
(получаю ошибку "Cannot create index on view "Test.dbo.OrdersView" because it uses a LEFT, RIGHT, or FULL OUTER
join, and no OUTER joins are allowed in indexed views. Consider using an INNER join instead.").
Теперь у меня есть несколько выходов, я вижу такие:
1) отказываеться от использования Left Outer Join (что фактичеси потребует, чтобы у меня в строках таблицы не было
NULL — значений, ну и вообще потребует некоторого изменения логики на уровне извлечения и записи данных).
2) перейти на SQL — базу данных, которая не обладает таким странным ограничением на одновременное использование LEFT OUTER
JOIN и индексирование полей View (например, на одну из версий Oracle)
3) Отказаться в этой задаче от реляционной базы вообще, и использовать какую нибудь нереляционную, например, MongoDB.
Фактически этот объект Order — это документ, у которого много полей. Похоже на то, что его удобно хранить в
документно — ориентированной базе.
Как Вы посоветуете мне решать эту проблему — хранения вообще и медленного поиска в частности?
