Рекомендации по дизайну на вид

Question

У меня есть вид (ObjectFlattenedView), который выравнивает точки данных из разных таблиц и представлений, содержащих все, что связано с объектом интереса. Затем Azure Search индексирует вывод этого представления для моего ui, чтобы позже вывести поисковые запросы, чтобы найти соответствующие записи. Объект имеет различные атрибуты (столбцы в представлении), которые мы могли бы искать. Вид довольно велик, поскольку количество объектов, а также различные источники атрибутов, поэтому производительность является серьезной проблемой.

У меня есть новый атрибут, который мне нужно добавить в этот сплющенный вид. Каждый объект имеет 0 до многих записей в этом TableN, которая имеет следующую структуру

ObjectId SubNo SubValue 
A   Sub5 0 
B   Sub1 0 
B   Sub2 1 
B   Sub.. .. 
B   SubK 0   

Теперь мне нужно, чтобы добавить новый атрибут (AttrN), так что я могу индексировать объект документы (в Azure Поиск называет), содержащую это новый атрибут. Уплощенный вид будет что-то вроде этого:

ObjectId Attr1...  AttrN  
A  abc.....  {Sub5:0} 
B  abd.....  {Sub1:0,Sub2:1,...SubK:0} 

Моя дилемма заключается в следующем:

Если я утончаются добавить КТР, объединяющее различные суб-значения объекта, производительность зрения ухудшается на 200% до 700%. Cte использует mssql's stuff и for xml. План выполнения показывает ~ 8% от общей стоимости этого заявления for xml. Я знаю, что будет влияние производительности, поскольку я присоединяюсь к другим таблицам/представлениям в своем сглаженном представлении, но порядок величины, с которым я попал, довольно высок.

Если я наружу, присоединитесь к моему ObjectFlattenedView непосредственно к TableN, тогда у моего представления будут записи для объектов, которые равны 1, количеству записей, которые объект имеет в таблицеN. Это усложняет обработку результатов поиска Azure, например, сколько записей требуется для поиска, а также разбиение на страницы, поскольку объекты могут содержать от 0 до M записей, начиная от TableN.

Кто-нибудь сталкивался с подобной проблемой, и у вас есть шаблоны, которые вы можете предложить для меня, чтобы справиться с этой ситуацией либо на стороне сервера sql, чтобы подать Azure Search с правильным набором строк, либо на стороне поиска Azure для обработки 0: M записей на объект (документ)?

Answer 1

Не уверен, что ниже будет полностью решена ваша проблема, но это может помочь. Несколько наблюдений:

1. Вместо создания единого убер-вид уплощение все, вы можете настроить несколько DATASOURCE/пар индексатора все записи в тот же индекс поиска - до тех пор, как все они сходятся на идентификатор документа , вы можете объединить данные и собрать свои документы поиска Azure по частям из нескольких источников.

2. Для обработки массивов значений у Azure Search есть коллекция (Edm.String) типа поля. Поскольку SQL не поддерживает массивы изначально, вы можете создать строковое поле в формате массива JSON (например, ["a", "b", "c"]) и использовать функцию jsonArrayToStringCollection, как описано в this article.

HTH!