Бил бы по рукам, да все линейки уже сломаны.

Поговорим о запросах. Точнее о том, как их надо писать, если хотите довести коллег до состояния старого чайника, который давно не мыли. С накипью.

1️⃣ Тянуть данные через весь запрос.

Если какое-то поле от ссылочного типа нужно в итоговом результате большого запроса, выберите его сразу, поместите во временную таблицу и перетаскивайте через каждое следующее использование - не дай бог к концу написания запроса забудется, какие именно поля нужны. А так - всегда перед глазами.

2️⃣Используйте для выражения замены в ЕСТЬNULL то, что может быть NULL или вообще вызвать ошибку.

К примеру, надо получить цену из какого-то регистра. Но ведь по соединению может получится так, что цена не найдена. Что тогда говорит насмотренность в таком случае: для левых соединений с негарантированным результатом, то есть вообще для всех, надо использовать функцию ЕСТЬNULL(ДанныеРегистра.Цена, ВыражениеЗамены)

Но тут пытливый мозг говорит: а почему 0? ведь если в регистре её нет, это не значит, что цены не существует, её же можно ещё рассчитать! И рождается великолепное ЕСТЬNULL(ДанныеРегистра.Цена, ДанныеДокумента.Сумма/ДанныеДокумента.Количество)

Никаких проблем, ведь пользователи же всегда стабильны в своём поведении, а значит количество чего-то всегда будет больше нуля. Мы не будем проверять это отдельно, потому что это трата ресурсов, сравнение числа с нулем съедает их просто невероятно.

3️⃣Используйте ВЫБРАТЬ РАЗЛИЧНЫЕ чтобы скрыть тот факт, что Ваше соединение - говно.

Вы же не дураки и знаете: если запрос возвращает несколько одинаковых записей, значит нужно выбрать только те, что уникальные. Не беда, что скля потратит ресурс сначала на лишнюю выборку, потом на удаление дублей. Мы ж как раз сэкономили на проверке количества.

Да и в конце концов не бывает же такого, что пользователь захочет вывести ещё какое-нибудь дополнительное поле, особенно из тех, что будут отличаться. Правда ведь?

4️⃣Для получения актуальных сведений используйте соединение с таблицей регистра сведений, а не его среза последних.

Особенно в формах списка. Нужно, чтобы пользователь сразу при открытии понимал, что у документа может быть несколько записей о статусе. Он, правда, сам этого не поймёт, но для этого есть же техподдержка, аналитики и тимлид. Они ему объяснят, что на самом деле сообщение "Обнаружено дублирование ключевых значений в колонках" - это не баг, а образовательная фича.

А если всё таки идёте против своей природы и обращаетесь к срезу последних - ни в коем случае не покрывайте поля индекса полностью, это для слабаков!

5️⃣Чтобы упростить поиск условий в запросе с большим количеством временных таблиц, накладывайте их, условия, в конце.

Нам не принципиальна выборка лишних данных. В конце концов, не мы же их тянем всё больше и больше с каждым соединением, а машина. А машина, как известно, надорваться не может. Зато все условия в одном месте и очень просто читаются. Профит!

В общем, используйте сами и другим подскажите. Только не долго, новые линейки уже заказал.

#медвежийкодстайл