Показать сообщение отдельно
Старый 14.03.2007, 13:35   #26  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5803 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Волчара Посмотреть сообщение
А вот писать такие запросы на 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; 14.03.2007 в 13:50. Причина: уточнение