Хинтовать или не хинтовать? Вот в чём вопрос!

Друзья, всем привет ☀️

Если вы когда-либо занимались оптимизацией запросов — наверняка рано или поздно вставал вопрос: использовать хинты или нет?

Интересно ваше мнение. Применяете ли вы хинты в проектах? При каких условиях? А может, у вас их вообще запрещено использовать?
👉 Поделиться мнением в чатике

Кстати, это видео — с практики пятого потока курса «Оптимизация Oracle SQL».
Тема оптимизации довольно сложная и без дополнительных встреч, было бы тяжело.
Поэтому каждую неделю, ребята собираются на 1–1.5 часа и обсуждают пройденный материал, делятся мнениями, задают вопросы.
Обычно минут 20 уделяем на "пробежаться по прослушанной лекции", далее практические моменты и Q/A.

Полную версию видео с ответом на вопрос про хинты опубликуем уже в четверг! 🎓

Всем хорошей рабочей недели! 🔥

#оптимизация #hints #Denis_Kivilev
Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

⚙️Одна из ТОП-болей Oracle-разработчика

Друзья, привет! Сохраните пост, чтобы показать тим-лиду и закрыть вечные споры на ревью 😉

БОЛЬ: Отсутствие единой системы стандартов форматирования кода в ORACLE❌

Как происходит в реальной жизни?
Приходишь в новый проект, открываешь код и получаешь мешанину из запросов.
У одного всё ЗАГЛАВНЫМИ, у другого строчными, третий чередует регистр через слово. Кто-то называет таблицы во множественном числе «Users», кто-то с префиксом tab_ - "tab_users", а где-то всплывает «user_tbl». Запросы форматируются как попало.
Каждый уверен: «Я так привык — значит, правильно». Единого документа нет, ревью превращается в мини-баттл, новичок тратит месяц, чтобы только «раскусить» локальные правила.

❌ СУТЬ ПРОБЛЕМЫ
У Oracle по-прежнему нет официального «ГОСТа» (и не будет) на оформление PL/SQL: нет аналога PEP-8 как в Python или Google-кодстайла как для Java. Всё держится на устных договорённостях и личных привычках. Каждая компания — маленькое «княжество» со своим письмом.

Итог хаоса
• читаемость падает;
• ревью затягиваются;
• баги всплывают на проде, потому что «не заметил в каше»;
• время онбординга увеличивается и т.п.

📉 К чему это приводит

Представьте, что всю жизнь ездили с левым рулём, а потом внезапно пересели на правый.
Первые дни — скорость падает, концентрация уходит в ноль, ошибок становится больше.
То же и с кодом: каждый новый проект — переучивание с нуля.
А бизнес-дедлайны никто не отменял: сроки горят, деньги утекают, команда нервничает.

🛠 Как можно это решить (и заработать очки в карму)🔥

1️⃣ Соберите мини-круг: пару тимлидов + самых заинтересованных разработчиков.

2️⃣ Сделайте короткий чек-лист с описанием:
 – единый регистр для ключевых слов и идентификаторов;
 – общие префиксы/постфиксы для таблиц, индексов и других объектов;
 – правила именования пакетов, процедур и др.;
 – правила написания комментариев и многое другое;

желательно, чтобы правила форматирования можно было задать в IDE.

3️⃣ Автоматизируйте проверку: поставьте любой SQL-formatter/linter в pre-commit.

4️⃣ Зашейте правило в CI: пока линтер красный, код не пройдёт.

5️⃣ Загрузите документ в Confluence и прикрепите ссылку в шаблон PR/MR.

6️⃣ Проведите мит-ап для разработчиков: объясните «зачем» это нужно.

⚠️ Важный момент: переформатирование существующей кодовой базы может выполняться по-разному. Команда выбирает, как лучше сделать.

💡 Фишка для проактивных

Видишь хаос? Предложи драфт-стандарт сам. Так ты:
• ускоряешь ревью;
• качаешь личный бренд «не ноет — решает»;
• чаще всего получаешь плюсик к росту до тимлида.

⚖️ Итог

Кодстайл — это не про «перфекционизм ради перфекционизма».
Это договорённость, которая превращает личные заготовки в командный актив.
Чем раньше вы договоритесь, тем меньше боли, нервов и денег потеряете.

📌 Сохрани себе и отправь тимлиду. Пусть стандарты работают, а люди пишут бизнес-логику, а не расставляют пробелы вручную.

А какие стандарты у вас были при смене работы, пишите в Чатик 💬 посмотрим, что за дичь есть на просторах.

Если пост наберет 100 🔥 расскажу как мы в Qiwi-решали эту проблему c автоматической проверкой PL/SQL-кода в CI. Проблема не простая, в виду того, что разработчики пользовались аж четырьмя разными IDE.

#Oracle #PLSQL #кодстайл #teamlead #Denis_Kivilev
Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Хинтовать или не хинтовать? Пусть решает команда

Я встречался с разными подходами и мнениями.

1️⃣ Например, в некоторых командах Qiwi было принято "не хинтовать". Поддерживай статистику в актуальном состоянии - тогда Oracle сам будет рулить с использованием CBO (cost based optimizer), и будет тебе счастье.
Вплоть до минуса на код-ревью. Система — OLTP.

К слову сказать, я не сильно полагаюсь на CBO, и если ты понимаешь логику работы запроса - то почему бы его не стабилизировать?
И в нашей команде хинтование я поощрял.

2️⃣ Например, в "IT Магнит" мы хинтовали почти все запросы. Это была специфика Big Data в DWH: параллельные запросы, временные таблицы… Очень часто CBO ошибался. Там без хинтов никак не обойтись.

3️⃣ Ещё один пример — из моей же практики. Пилили коммерческое ПО для банков. Сколько тогда поели г...на из-за CBO у заказчиков.
К слову сказать, пилить ПО на заказ и поставлять его в разные организации — это задачка на порядок сложнее, чем когда система твоя, до которой ты можешь легко дотянуться.

Например, у тебя 10 заказчиков, и у всех у них есть какие-нибудь свои прикольчики.
Допустим, админы в банке решили не собирать статистику. Да, такое бывает. Ну и какой, на фиг, CBO поможет с запросами при такой постановке?

Поев немало... проблем, мы коллегиально решили хинтовать максимум запросов.

Если стоит выбор между «срочно решаем проблему на ПРОДе у заказчика» и «заранее хинтануть запрос и не иметь геморроя» — я выбираю второе 😊

Подводя итог
Универсального ответа нет. Каждый случай индивидуален по-своему. Решайте командой.

Каким принципом руководствуетесь вы? Что думаете? Обсудить в чатике 💬

Кстати, это видео — с практики пятого потока курса «Оптимизация Oracle SQL» ❤️

#Denis_Kivillev #оптимизация #hints
Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Запрос 1️⃣

Запрос 2️⃣

Запрос 3️⃣