Что лучше сделать три левых соединения последовательно через временные таблицы или в одном запросе сразу три соединения?

в одном запросе сразу три соединения, если они простые

Таки хез. у меня пять простеньких соединений (к допреквизитам) сегодня выбили сервер недостатком всего. Я плакал.

три белых коня, три белых коня...

мозги не [...]. делай временные. не прогадаешь точно. бгг
мы ж не знаем, что у тебя за ПО и ГДЕ

(2) допреквизиты с типом любая ссылка? чего ж вы хотели батенька

(2) Типизируй в соединении и будет гуд работать.

даже я помню про то, что любую ссылку типизировать надо

Кстати вот еще в тему вопросик будет =

а как это работает? Например, у нас 10 тысяч записей, и нужно отобрать по различныи условиям, если я в начала поставлю условие на период, условие на реквизит тех документов которые мне нужны, от быстрее ли отработает? Еже ли эти данные стояли бы в конце?

(8) все зависит от того, как построен индекс - кури план запроса.

(9) Ок, а план запроса это что такое? Это отдельная подсистема?

(10) wiki:План_выполнения_запроса

Спасибо всем за подсказки!

(8) Общий принцип - накладывать условия отбора как можно раньше.

(8)>а как это работает?
Смотри план выполнения запроса. Если ClusterIndexSeek/IndexSeek - удачно запросил

(14)

Если ClusterIndexSeek/IndexSeek - удачно запросил

В общем случае подход ошибочен. Имеет смысл смотреть стоимости отдельных частей сравниваемых планов и, разумеется, общую стоимость плана в целом.

(15)если нет сканов это плохо? Хотя фактическаЯ стоимость может быть плохой, например из-за статистики, параметрс снифер и т.п.

(16) Если таблица маленькая, использование индекса может не дать прироста в скорости. Зато создание и поддержание индекса съест ресурсы. Не валидная статистика обычно проявляется выбором очевидно не оптимальных планов.

(17)индекс у физ. таблицы уже как-бэ есть, а вот оптимизировать для мелких таблиц - дурной тон, там и по плохому плану будет быстро.

(18) "Родного" кластерного индекса обычно бывает недостаточно. Что заметно по операциям index scan.

Что таблица внезапно окажется мелкой очевидно бывает не всегда. Я имею в виду временные таблицы разумеется.

Всем привет!

Вот есть такой вопрос= есть таблица по договорам и у этих договоров 7 таблиц, из которых нужно получить данные, как лучше сделать?
Левым соединением или еще как то моно?

ещё как то можно

Всмысле имеется ввиду что сами договора делают движение по 7ми интересующи регистрам, но тк мы говорим о 3х миллионах записей то как оптимизировать?

индексами и отборами

(23) отборами понятно , накладывая отбор по периоду на присоединяемые таблицы, акак это индексами? Что имеется ввиду?

если проводить отбор/соединение по индексированному полю, то это обычно быстрее

(22) Ты ничего не путаешь? Обычно договора это справочник, регистры двигать не умеют.

(27) Он видимо хочет по списку договоров выбрать все их движения по 7-ми регистрам.

(27)справочники и регистры? - Фигня! Я видел зп на РС!!! Вот где жёсть жестянная!!!

(27) Как это договора = справочник?

По каким данным собственно нужен отбор?

(31) Сперва отбираешь из таблицы договоров ссылки только на нужные элементы. Потом левым соединением цепляешь к ним детализации из РС и ТЧ.

(33) а если отбор нужен и по рекизитам левосоединенных данных? вот тут все нюансы

(34) Добавляем в раздел ПО что-нибудь вроде:

И ИскомыйРеквизит = &ЗначениеПоиска

ТеньД + (34) Хуже когда архитектура продумана жопой, тогда начинается херня с отбором по ПОДОБНО

был у меня один такой архитектор. Вечно у него в ключевых полях по два префикса было...

(37) Увы, мне далеко идти за примерами не придется. Недавно самому пришлось рисовать в запросе получение данных из таб. частей документов. Потому как регистр Товары на складах, где все нужные данные лежат, оказался спроектирован так, что выборка данных по нему оказалась на 3 порядка медленнее.

(38) потому что АналитикаУчетаПоНоменклатуре?

(39) Надо получить кол-во поступлений товаров за всю жизнь. РН ТоварыНаСкладах спроектировали без индексов по измерениям. Получение цифири из него приводит к неэффективному index scan, перебору почти всех записей. Таблицу ТЧ Товары ПТУ тоже приходится перебирать всю, но там намного меньше записей чем в РН, в который пишут все кому ни лень.

(40) и что, страшно было, да? [smile=XD]

(41) Глаза боятся - руки делают.

ТеньД к неэффективному index scan

это что-то плохое?

(43) Когда приходится перелопачивать таблицу на 50 лямов записей то это очень плохо. В том случае от кластерного индекса отрабатывало только условие ССЫЛКА Документ.ПоступлениеТоваровУслуг.