Используйте CASE вместо сложных вложенных предикатов

В работе с конструкцией WHERE есть один хитрый ход — использовать выражение CASE для сложного предиката с логическим следованием. Если вы забыли логику, преподаваемую на первом курсе, логический оператор следования записывается как стрелка и означает “из р следует q” или “если истинно р, то истинно и q”:

WHERE CASE

WHEN <условие поиска #1> THEN 1

WHEN <условие поиска #2> THEN 1

ELSE 0 END = 1

Функция, которая возвращает единицу или ноль, принимая предикат в качестве параметра, в логике и теории множеств называется характеристической функцией. Посмотрите еще раз правила для выражения CASE в разделе “Использование выражений CASE” и вы поймете, о чем речь. Определенный порядок выполнения конструкций WHEN можно использовать для оптимизации действия программы и избавления от излишних проверок. Вы также вольны помещать выражения CASE внутри конструкций WHEN и THEN, содержащих выражение CASE и представлять логику этой конструкции в виде древовидной структуры:

WHERE CASE

WHEN <условие поиска #1> THEN CASE

WHEN <условие поиска #1.1>

THEN 1

WHEN <условие поиска #1.2>

THEN 1 ELSE О END WHEN <условие поиска #2> THEN 1

ELSE 0 END = 1

Главная цель, которую преследует эта техника, заключается в замене длинных списков выражений внутри громоздких многоуровневых скобок. Когда уровень вложенности становится совсем уж недоступным для понимания, остановитесь и пересмотрите логику, которой вы следуете. Использование специальных средств для управления таблицами, например Logic Gem, — прекрасный путь для достижения этой цели.

Используйте комментарии

Обоснование
Лучшим видом документации программы являются комментарии. Возможно, программистам, работающим на процедурных языках, добавлять комментарии проще, поскольку они объясняют в повествовательной манере, что делает программа. К сожалению, комментарии, принятые в процедурных языках, часто являются излишними для того, кто умеет читать код. Насколько полезен будет приведенный ниже комментарий?

UPDATE Teams

SET score = score + 1; --увеличение счета

Он не дает информации о том, что означает этот “счет” и почему его нужно увеличивать.
В стандартном SQL комментарии начинаются с двух черточек (--) и заканчиваются с началом новой строки, так как первые реализации SQL были написаны для мэйнфреймов IBM и использовали перфокарты. Для современных компьютеров такой вариант неудачен, так как они способны хранить текст в свободном формате. Разбиение текста программы на строки может расщепить комментарий и приведет к сообщению об ошибке. Кроме того, SQL поддерживает унарный оператор вычитания, поэтому такие комментарии в некоторых редких случаях могут стать двусмысленными и очень сильно затруднить работу компилятора. В более поздних стандартах для обозначения комментариев предусмотрена пара символов /* и */ в стиле языка Си. Лучше всего пользоваться именно ими. Похожие пары скобок предусмотрены и многими разработчиками.
SQL-программисты не любят сопровождать код комментариями, вероятно, из-за того что SQL выполняет много действий в одном операторе, а программисты приучены давать комментарии на уровне отдельных операторов, а не описывать предназначение кода в целом. Более высокий уровень абстракции запутывает их. Они не хотят помещать комментарии на уровне конструкций, поскольку с их точки зрения это портит внешний вид кода.
Преодолейте это. Вам необходимы комментарии, описывающие блоки SQL на высоком уровне, а также более детальные комментарии для особенно важных конструкций. Постарайтесь составлять комментарии, не нацеленные специально на SQL-программистов, и пишите их на простом языке. Например, не говорите “реляционное деление транспортных средств на доступных водителей”, подразумевая, что читатель знает, что такое “реляционное деление”. Вместо этого напишите “список водителей, которые могут управлять всеми транспортными средствами в гараже”. Давайте ссылки на документацию к схеме и приложению. Это, конечно, подразумевает, что эта документация есть, актуальна и хорошо составлена.
Если у вас есть достаточно времени, вы можете как настоящий гуру SQL-программирования применить и такой прием. Сохраняйте в качестве комментариев те выражения, что успешно выполняли поставленную задачу, но были затем заменены лучшим вариантом. В SQL то, что было лучшим в одной ситуации, часто вскоре перестает быть таковым. Не заставляйте следующего программиста начинать с “чистого листа”, поделитесь с ним своим опытом.

Исключения
При наличии тщательно проработанной схемы и хороших имен элементов данных, опытный программист легко прочитает большую часть кода.
Вы можете пропустить описание некоторых переменных и операторов, если их предназначение очевидно. Впрочем, помните: то, что очевидно одному программисту, у другого при чтении кода вызовет вопрос: “Что за чертовщина?”.

Хранимые процедуры

Всегда начинайте хранимую процедуру с комментария, который, как минимум, содержит информацию об авторе, дате написания и последовательности вносимых в нее изменений. Это требование — основа управления ПО. Добавьте подробное описание назначения модуля. Имя процедуры должно иметь вид “<действие><объект>”. При необходимости снабдите комментарием каждый параметр.