Сложная выборка многие-ко-многим

[skof]

Добрый день!
проблема такая - есть поставщик (VendTable) у него отношение многие ко многим с категориями (EcoResCategory) посредством (VendCategory)
[VendTable] 1--* [VendCategory] *--1 [EcoResCategory]
есть список категорий, выбрать поставщика у которого есть хотя бы одна из указанных категорий - легко. Но! Задача стоит чтобы выбрать поставщиков у которых есть все указанные категории.
Есть идеи как такое сделать?
Дополнительным условием стоит то что надо все это вложить в QueryBuild.

[raz]

Может быть сделать view, где будет field1 = count() по категориям, далее приджоинить этот view, где field1 >= нужного числа?

[gl00mie]

Непонятно, в чем подвох. Есть VendCategory - кросс-таблица для комбинаций поставщик-категория. Если есть N категорий, и нужно отобрать поставщиков, по которым в кросс-таблице есть записи для каждой из этих N категорий, то по идее в Query надо сделать одну выборку (qbds) из VendCategory по 1-й категории и N-1 выборок из VendCategory по exists join для оставшихся категорий со связкой по ссылке на поставщика из 1-го qbds.

[skof]

Цитата:

Сообщение от raz

Может быть сделать view, где будет field1 = count() по категориям, далее приджоинить этот view, где field1 >= нужного числа?

Да! Это мысль!

[skof]

Цитата:

Сообщение от gl00mie

Непонятно, в чем подвох. Есть VendCategory - кросс-таблица для комбинаций поставщик-категория. Если есть N категорий, и нужно отобрать поставщиков, по которым в кросс-таблице есть записи для каждой из этих N категорий, то по идее в Query надо сделать одну выборку (qbds) из VendCategory по 1-й категории и N-1 выборок из VendCategory по exists join для оставшихся категорий со связкой по ссылке на поставщика из 1-го qbds.

т.е. нужно добавить столько qbds сколько категорий выбрал пользователь?

[S.Kuskov]

Цитата:

Сообщение от raz

Может быть сделать view, где будет field1 = count() по категориям, далее приджоинить этот view, где field1 >= нужного числа?

А что при фильтрации пользователь гарантировано указывает полный исчерпывающий набор категорий поставщика?. В таком случае задачу можно решать от обратного - выбирать поставщиков у которых нет других(не выбранных) категорий, не забыв отсечь поставщиков вообще без категорий.

Иначе количество во View должно быть посчитано по уже отфильтрованным категориям!
Поэтому View либо нужно каким-то образом строить на лету(?), либо фильтровать View при помощи вспомогательной таблицы, в которую перед выборкой заполнять выбор пользователя. Но для этого в свою очередь нужно решить задачу разграничения данных для одновременной работы нескольких сессий с этой таблицей, и тащить в результирующий View ещё и идентификатор фильтрующей комбинации.

А насколько произвольным может быть выбор пользователя? Нельзя ли построить работу так, чтобы пользователи сначала формировали некие общие для всех комбинации, а потом при фильтрации не указывали набор категорий, а выбирали из уже готовых?

P.S. Сдаётся мне, что примерно для этих же целей в AX2012 ввели понятие "наборов аналитик".

[gl00mie]

Цитата:

Сообщение от skof

т.е. нужно добавить столько qbds сколько категорий выбрал пользователь?

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

• взять первые 15 выбранных категорий,
• сузить выборку по поставщикам
• взять следующие 15 выбранных категорий, при этом фильтровать по поставщикам, отобранным на предыдущем шаге
• etc

Дополнительно можно применить предложенную view'шку по количеству заданных для поставщика категорий. Но в целом решение сильно зависит от ваших конкретных данных.

[Ruff]

Цитата:

Сообщение от S.Kuskov

Иначе количество во View должно быть посчитано по уже отфильтрованным категориям!
Поэтому View либо нужно каким-то образом строить на лету(?), либо фильтровать View при помощи вспомогательной таблицы...

Мне кажется, тут поможет HAVING. Группируем кросстаблицу по поставщику, считаем число категорий и сравниваем с числом выбранных категорий (оно по идее должно быть известно из интерфейса).
Что то типа такого :

qbdsVendor = query.addDataSource(...);
...
qbdsVendCat = qbdsVendor.addDataSource(...);
...
qbdsVendCat.addGroupByField(fieldNum(VendCategory, VendorId));
qbdsVendCat.addSelectionField(fieldNum(VendCategory, CategoryId),SelectionField::Count);
...
query.addHavingFilter(qbdsVendCat, "Category", AggregateFunction::Count).value(strfmt("==%1", _selectedCatNum));

[S.Kuskov]

Ух ты! В 2012-ой появился HAVING. Не знал. Тогда да , наверное можно без View обойтись и на лету весь запрос собрать.

Но для полного счастья нужно ещё суметь присоеденить к таблице поставщиков этот ограниченный при помощи группировки подзапрос как вложенный. По опыту работы с предыдущими версиями группировка в сложном запросе выполняется после джойнов и применяется ко всему запросу (. Может быть если делать связи на уровне датасурсов формы оно сработает?

[gl00mie]

На лету может не получиться, если выбранных категорий может быть достаточно много, хотя, конечно, в пределах пары десятков категорий можно, наверно, выбрать и за раз.
Небольшое дополнение касаемо having: там, наверно, все же надо использовать условие >=

[Ruff]

Цитата:

Сообщение от gl00mie

Небольшое дополнение касаемо having: там, наверно, все же надо использовать условие >=

Я не уточнил, что кросс-таблица должна быть уже отфильтрована по категориям (Range-ом или exists join-ом). И в этом случае условие "больше" просто никогда не выполнится. Так как если группировать нефильтрованную кросс-таблицу, то условие "больше" вполне может сработать для поставщиков, у которых просто много категорий, но части выбранных - нет:

пост кат
а 1
а 2
а 5
а 6
а 7
б 1
б 2
б 3
б 4

выбор польз-ля: 1, 2, 3

если не фильтровать, то получаем:
а 5 (>=3) - ОК
б 4 (>=3) - ОК

а если с фильтром "1,2,3" :
а 2 (==3) - FAIL
б 3 (==3) - OK

PS: решал похожую задачу, правда она была сложнее, в итоге пришлось вообще делать прямые SQL-запросы с HAVING-ом и кучей вложенных селектов

[Alex_KD]

Случаем не стандартную view хотите переписать?
ProcCategoryVendorView