SQL и тайны коридоров Хогвартса

Да запятые эт отдельная тема для холивара. Те же trailing запятые (не в SQL, но к примеру в js) кто-то любит, кто-то нет (я). Кто-то для избавления от trailing запятых начинает добавлять leading запятые, примерно как в посте (не я).

Тут и люди с отступами табами могут повозмущаться.

Идея вертикальной линии мне в целом нравится, если редактор или IDE будет уметь это делать автоматом. Если нет, можно и не заморачиваться на мой взгляд.

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

У лидирующей запятой есть плюс - легко закоментить конкретную строку или вклинить еще одну. Во времена динамического построения запросов - это было очень удобно. Такой вот модулярный формат получался.

Истинно )))) Но автор - все равно красивчик

Так лучше. Коридор с точки зрения типографики, возможно, красивое. Но лучше всё же видеть структуру заклинания.

То что надо, я так же форматирую, с одним изменением: таблицы employee и departments тут равнозначны (можно поменять местами, ничего не изменится), нет причины сдвигать правую часть JOIN вбок. Я форматирую

FROM
    employee e
JOIN
    departments d
    ON d.id = e.dept_id

Или короткий вариант,

FROM employee e
JOIN departments d
    ON d.id = e.dept_id

Общая идея, что FROM и JOIN равноуровневые конструкции.

Вот вариант от меня. Компактный, коридорно-блочный. На первый взгляд выглядит перегружено, но читается очень просто. Пользуюсь много лет.

/* запрос попроще */
SELECT e.first_name, e.last_name, e.salary,
       d.name AS department_name,
	     j.name AS job_name
  FROM employee e
  JOIN departments d
    ON d.id = e.dept_id
  JOIN jobs j
    ON j.id = e.job_id
 WHERE d.name = 'IT' 
   AND j.name = 'Engineer' 
   AND e.salary > 100;

/* запрос посложнее */
SELECT e.first_name, e.last_name, e.salary,
       d.name, j.name,
       ( SELECT SUM(o.cost)
           FROM orders o
          WHERE o.employee_id = e.id 
            AND o.status = 'closed' 
       ) AS sum_cost
  FROM employee e
  JOIN departments d
    ON d.id = e.dept_id
	
  JOIN jobs j
    ON j.id = e.job_id
   AND ...
   AND ...
   
  LEFT JOIN jobs2 j2
    ON j2.id = e.job_id	
 WHERE e.salary > ( SELECT AVG(se.salary)
                      FROM employee se
                      JOIN departments sd
                        ON sd.id = se.dept_it
                     WHERE d.name = 'IT' 
                  );

• Служебные слова в верхнем регистре

• Разбиение запросов и подзапросов на коридоры и блоки

• Все служебные команды всегда с новой строки, за исключением AS

• Пустой строкой можно выделять сложные блоки, требующие внимания

• Скобки - всегда в одну линию

• AND и OR - для каждой вложенности должен быть сделать отступ

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

• Можно делать бесконечное количество вложенных запросов, но, при этом они все будут выглядеть одинаково, компактно и читаемо

Схемка

я вот так бы отформатировал

/* запрос попроще */
SELECT  e.first_name,
        e.last_name,
        e.salary,
        d.name AS department_name,
        j.name AS job_name
FROM    employee e
JOIN    departments d ON d.id = e.dept_id
JOIN    jobs j ON j.id = e.job_id
WHERE   d.name = 'IT' AND
        j.name = 'Engineer' AND
        e.salary > 100;
/* запрос посложнее */
SELECT  e.first_name,
        e.last_name,
        e.salary,
        d.name,
        j.name,
        (
            SELECT  SUM(o.cost)
            FROM    orders o
            WHERE   o.employee_id = e.id
            AND     o.status = 'closed'
        ) AS sum_cost
FROM    employee e
JOIN    departments d ON d.id = e.dept_id
JOIN    jobs j ON j.id = e.job_id
WHERE   e.salary > (
    SELECT  AVG(se.salary)
    FROM    employee se
    JOIN    departments sd ON sd.id = se.dept_it
    WHERE   d.name = 'IT'
);

/* запрос попроще */
select e.first_name as first_name,
       e.last_name  as last_name,
       e.salary	    as salary,
       d.name       as department_name,
       j.name       as job_name
  from employee e
  join departments d
    on d.id = e.dept_id
  join jobs j
    on j.id = e.job_id
 where d.name = 'IT' 
   and j.name = 'Engineer'
   and e.salary > 100;

/* запрос посложнее */
select e.first_name,
       e.last_name,
       e.salary,
       d.name,
       j.name,
       (select sum(o.cost)
          from orders o
         where o.employee_id = e.id 
           and o.status = 'closed') as sum_cost
  from employee e
  join departments d
    on d.id = e.dept_id
  join jobs j
    on j.id = e.job_id
 where e.salary > (select avg(se.salary)
                     from employee se
                     join departments sd
                       on sd.id = se.dept_it
                    where d.name = 'IT');
                    
/* пример case */
select case
         when col_1 = 1
         then 1
         when col_1 = 2 and col_2 = 1
         then 2
         when col_1 = 3 
          and col_2 = 1 
          and col_3 = 2 
          and col_4 = 3
         then 3
         else 4
        end as test_case
  from test_table

1. Служебные слова не выделяются регистром. Это вроде как принято сообществом за условие по умолчанию, но пользуясь приведённым мной кодстайлом несколько лет, я не вижу смысла в выделении капсом. Служебные слова выделяются цветом. Это одновременно действенно и не раздражает глаз при просматривании кода.

   Строки, например, не выделяются ничем кроме цвета (кавычки в расчёт не беру т.к. попробуйте отключить подсветку в запросе с кучей строк и конкатенацией) и это никак не мешает их распознаванию.

2. Тот самый "коридор". Это красиво) И в то же время это дополнительный уровень отделения служебных слов от остального текста. К тому же, коридор довольно простой в распознавании и написании принцип. Все служебные слова выстраиваются вдоль него, а не по какой-то сложной, ветвистой логике.

3. С case всё сложнее. Мне сложно сказать оптимален ли приведённый мной пример написания case даже для меня. Пока я пришёл к тому, что в зависимости от конкретной ситуации case будет лучше читаться и выглядеть в разных стилях.

Всё описанное - ИМХО, да и вообще, тема стайлгайдов как по мне хоть и имеет под собой какую-то объективную базу, но как будто бы, эта база совсем небольшая (если она там вообще есть), а вот всю остальную долю темы занимает субъективное восприятие людей, которое довольно хорошо подстраивается под разные условия. Если бы мне приходилось писать несколько лет запросы в стиле EvilMan то, вероятно, я бы так же находил плюсы в этом стиле и не хотел писать по другому :)

P.S. редактор комментариев хабра для меня загадка. При написании/редактировании подсветка SQL кода одна, а после отправки комментария - другая. Да ещё и после отправки отредактированного комментария подсветка вообще слетает, и появится только после обновления страницы.

Безусловно это все вкусовщина, но в вашем примере код стал вертикально "выше". В последнем примере ко всему прочему добавились горизантальные пробелы. В итоге код стал "размазан", снизилась концентрация, стало немного сложнее читать.

На правах ИМХО

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

За несколько лет работы с SQL скриптами я пришел к похожему форматированию, особенно после того как пришлось разбираться со скриптами уволившихся коллег

-- в SELECT разбиваем 100500 выводимых колонок на логические группы, 
-- каждая из которых начинается с новой строки
SELECT e.first_name, e.last_name
      ,e.salary
      -- любое изменение будь то введение alias'a, формула и тд 
      -- пишем с новой строки, один столбец - ода строка
      ,d.name AS departament_name
      ,j.name AS job_name

-- также одна строка отступа перед FROM и перед каждым очередным JOIN
-- это визуально разделяет запрос на группы
FROM employee e

JOIN departments d
    -- магическая строка 1 = 1 всегда равна TRUE и потому игнорируется
    -- но позволяет в КАЖДОЙ строке условия писать AND в начале строки
    -- по той же причине по которой мы пишем "," в начале строки в SELECT  
    ON 1 = 1
    AND d.id = e.dept_id
    
JOIN (
    -- в простых запросах скорее всего нет смысла делать отступы перед FROM или WHERE 
    -- это усложнит чтение
    SELECT * 
    FROM jobs
    WHERE 1 = 1 
    AND REGEXP_LIKE(name, '([^=,]+)', 1, 4) = 'WTF'
) j
    ON 1 = 1 
    AND j.id = e.job_id
    
WHERE 1 = 1
    AND d.name = 'IT' 
--  AND e.last_name <> 'Ivanov'
    AND j.name = 'Engineer' 
    AND e.salary > 100

Так же с недавнего времени пришел к выводу, что если мы не придерживаемся синтаксиса полного именования

schema.departament.name = schema.wfttable.departament

а пользуемся псевдонимами для таблиц, то это очень быстро родит путаницу с названиями полей. Поэтому на мой взгляд, несмотря на лаконичность названий id, name, description и других "общих" названий и зарезервированных ключевых слов, стоит называть их как departament_id, departament_name, departament_description и тд.

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

То есть правильно

WHERE {condition 1}
  AND {condition 2}

а вовсе даже не

WHERE {condition 1} AND
      {condition 2}

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

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

Мои 5 копеек (вот тут живет форматтер по этим правилам):

SELECT
  e.first_name
, e.last_name
, e.salary
, d.name department_name
, j.name job_name
FROM
  employee e
JOIN
  departments d
    ON d.id = e.dept_id
JOIN
  jobs j
    ON j.id = e.job_id
WHERE
  d.name = 'IT' AND
  j.name = 'Engineer' AND
  e.salary > 100;

SELECT
  e.first_name
, e.last_name
, e.salary
, d.name
, j.name
, (
    SELECT
      sum(o.cost)
    FROM
      orders o
    WHERE
      o.employee_id = e.id AND
      o.status = 'closed'
  ) sum_cost
FROM
  employee e
JOIN
  departments d
    ON d.id = e.dept_id
JOIN
  jobs j
    ON j.id = e.job_id
WHERE
  e.salary > (
    SELECT
      avg(se.salary)
    FROM
      employee se
    JOIN
      departments sd
        ON sd.id = se.dept_it
    WHERE
      d.name = 'IT'
  );

• служебные слова в uppercase, чтобы сразу бросались в глаза

• смещение "уровня" в 2 пробела

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

• AS убирается везде, где это допустимо

• WITH-SELECT-FROM-JOIN-WHERE-GROUP-HAVING-ORDER-LIMIT задают первый уровень запроса, таблицы и WHERE-условия - второй, ON - третий

• подзапросы всегда с новой строки

1. Служебные слова выделяются цветом и так, а верхний регистр напрягает глаза(субъективно).

2. В разбиении секции join на несколько строк тоже не видно необходимости, т.к. есть тоже цветовое разделение. При таких частых переносах где только можно текст превращается в простыню, которую не видно и листать приходится.

3. В целом код должен быть легко читаемым на логическом уровне с равномерным заполнением по горизонтали и вертикали(гармония)

LEFT OUTER JOIN  - еще веселей и реалистичнее.

Похоже генетическая память, многие так привыкли. По той же причине по которой секции светофора делают до сих пор круглыми

• выполнение/редактирование кода в консоли

• чтение запросов в логе

во многих соглашениях прикладных ЯП принято константы писать большими буквами, не думаю что у многих при виде таких констант вспоминается 386 комп и BASIC.