Query из 7 таблиц

[slava]

Цитата:

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

На Ax 4.0 те же яйца.

Я в шоке
Стоит уже делать ставки в каком десятилетии исправят.

[Волчара]

Цитата:

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

Я в шоке
Стоит уже делать ставки в каком десятилетии исправят.

Да не стоит напрягаться - не такая это уж и серьезная ошибка.
Со стороны Microsoft разумно заявить четкое ограничение на количество таблиц в Query.

А вот писать такие запросы на 7 таблиц - есть большая ошибка.
Cornflower - вы моделировали этот запрос в SQL Query Analyzer? Если нет то попробуйте - может он вам все так подвесит, что и возиться не стоит?

[gl00mie]

Цитата:

Сообщение от Волчара

А вот писать такие запросы на 7 таблиц - есть большая ошибка. Cornflower - вы моделировали этот запрос в SQL Query Analyzer? Если нет то попробуйте - может он вам все так подвесит, что и возиться не стоит?

Неправда ваша, бывает нужно и большее число таблиц связать - в основном это, конечно, одна-две транзакционные таблицы и куча справочников. Простой пример: нужно построить отчет по нескольким компаниям с накладными по поставщикам в разрезе договоров, поставщики группируются по внешним кодам, в отчете отдельно выделяются суммы по накладным расходам, распределенным на строки номенклатуры, при этом отфильтровываются "внутренние" контрагенты, связанные через CommerceGateway с другими компаниями, т.е. если поставщик DAT связан с компанией DAT, то он в отчет попасть не должен. Для отчета берутся: VendInvoiceJour, VendInvoiceTrans, VendTable, ExtCodeValueTable, RContractTable, GatewayOrgRef, GatewayOrganization и MarkupTrans (это если использовать MarkupTrans.CustVendPosted_RU, иначе еще придется цеплять MarkupTable) - итого 8 таблиц. Первым делом строится запрос SQL и прогоняется в Query Analyzer, чтобы посмотреть, те ли вообще данные получатся на выходе и за какое время они получатся, а уже потом это все переводится в Query, и начинается мучительная борьба с ограничениями и бзиками парсера запросов

[Волчара]

Цитата:

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

...нужно построить отчет по нескольким компаниям с накладными по поставщикам в разрезе договоров, поставщики группируются по внешним кодам, в отчете отдельно выделяются суммы по накладным расходам, распределенным на строки номенклатуры, при этом отфильтровываются "внутренние" контрагенты, связанные через CommerceGateway с другими компаниями, т.е. если поставщик DAT связан с компанией DAT, то он в отчет попасть не должен. Для отчета берутся: VendInvoiceJour, VendInvoiceTrans, VendTable, ExtCodeValueTable, RContractTable, GatewayOrgRef, GatewayOrganization и MarkupTrans (это если использовать MarkupTrans.CustVendPosted_RU, иначе еще придется цеплять MarkupTable) - итого 8 таблиц. ...

Такой query со связями 1:n превратиться в SQL в несколько вложенных запросов. По этому с точки зрения загрузки сервера это менее актуально.

Кстати, возможно для такого Query - количество таблиц и не имеет столь жестких ограничений. Ни кто не проверял ?

Наконец если при настройке системы позаботиться об этом заранее, то можно сократить Query на 2-3 таблицы.

[Morpheus]

Цитата:

Сообщение от Волчара

Такой query со связями 1:n превратиться в SQL в несколько вложенных запросов. По этому с точки зрения загрузки сервера это менее актуально.

Наконец если при настройке системы позаботиться об этом заранее, то можно сократить Query на 2-3 таблицы.

Ну Вы заладили... А если модификацию необходимо выполнить в функциональности где все сущности уже спроектированы и реализованы... А необходимо в какую-нибудь форму добавить в источник данных еще одну табличку для наложения фильтра... потом можно и тонким тюнингом заняться для ускорения работы СУБД...

[gl00mie]

Цитата:

Сообщение от Волчара

Кстати, возможно для такого Query - количество таблиц и не имеет столь жестких ограничений. Ни кто не проверял ?

Я проверял - половина таблиц не выбирается, пришлось возиться с подзапросами и кэшировать данные в Map'ах.

Цитата:

Наконец если при настройке системы позаботиться об этом заранее, то можно сократить Query на 2-3 таблицы.

Угу, обзывать всё и во всех компаниях одинаковыми кодами, поналепить в таблицы с проводками кучу дополнительных полей, дублирующих данные из справочников, вместе с кособокими неповоротливыми механизмами, обновляющими эти данные при изменении справочников, сюда не ходить, здесь не смотреть и вообще свести работу SQL-сервера к выборкам со сложностью на уровне dbf.

[Волчара]

Цитата:

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

Я проверял - половина таблиц не выбирается, пришлось возиться с подзапросами и кэшировать данные в Map'ах.

Ладно, убедили - пишите в Микрософт коллективную жалобу...