Как правильно оформить sql-запрос чтобы он был читаемый?

Question

[LordOfARing]

Есть такой простой SQL-запрос. Он корректный, выводит то что мне и надо. Как мне его оформить правильно, чтобы было "по-науке"? Какую еще табуляцию написать?

with sum_bon as
(
select worker_ref_id
    , employee_title
    , sex
    , sum(bonus) as sbon 
from sf_employee as sfe
inner join sf_bonus as sfb
on sfe.id=sfb.worker_ref_id
group by employee_title
    , sex
    , worker_ref_id
)

select sum_bon.employee_title
    , sum_bon.sex
    , avg(sfe.salary+sbon) compensation 
from sf_employee as sfe
inner join sum_bon
on sfe.id=sum_bon.worker_ref_id
group by sum_bon.employee_title,
    sum_bon.sex

Comments

[Macaronin]

Работает и хорошо, а оформление - дело вкуса

[Akina]

Сугубо индивидуально. Правил нет.

Из недочётов (согласно сказанному выше - ИМХО):

1. Рекомендуется выравнивать ВСЕ одноуровневые термины. А у тебя первое имя поля в списке смещено относительно других - что в списке вывода, что в выражении группировки.
2. Субтермин (ON, CTE) лучше располагать под термином (JOIN, WITH) с дополнением уровня, а не на одном уровне.

Answer 1

[alexalexes]

У меня сформировалась такая модель оформления запросов sql.
1. Один уровень запроса я насаживаю на ось. Слева от оси - клаузы синтаксиса sql: select, update, insert, delete, from, set, join-ы всех разновидностей, where, order by, group by и так далее. Справа от оси - атрибуты запроса, скобки следующего уровня запроса.
2. В выражениях оконных функций делаю ось относительно partition by/order by.
3. Булевые выражения после on или where выравниваю так:
- операторы первого приоритета (and) идут в левую часть оси;
- сравнения и следующий уровень более низкого приоритета (or) - в правую часть оси.
4. наименования join сокращаем максимально кратко:
- вместо inner outer join просто join,
- вместо left outer join - left join и так далее.
5. В части join...on присоединяемые поля таблицы ставлю в левую часть равенства в булевых выражениях:

join t1 on t1.a_id = t2.id
           and t1.begin_date < t2.end_date

но не так:

join t1 on t2.id = t1.a_id
           and t2.end_date > t1.begin_date

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

select a.id, a.name,
         b.position
         ...

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

select a.id
          , a.name
         , b.position

после:

select a.id, a.name,
          b.position

Итог. Эта модель не идеальна. Нужно делать отступы для select и from на первом уровне, чтобы посадить на ось where, group by, order by; также join-ы следующего уровня напирают на ось предыдущего.
PS: Ваш запрос я бы оформил так:

Answer 2

[Алан Гибизов]

Тело with в скобках я бы сдвинул на таб вправо, и странные запятые в начале строк убрал бы взад.
Также inner join вправо на таб вместе с on- потому что оно вместе с первой таблицей является подуровнем from.
Но вообще это вкусовщина, и если требований не зафиксировано где-нибудь в ВНД, то хоть в одну строчку пиши всё...
Как-то

так

with sum_bon as
(
    select 
        worker_ref_id, 
        employee_title, 
        sex, 
        sum(bonus) as sbon 
    from 
        sf_employee as sfe
        inner join sf_bonus as sfb
        on sfe.id=sfb.worker_ref_id
    group by 
        employee_title, 
        sex, 
        worker_ref_id
)

select 
    sum_bon.employee_title, 
    sum_bon.sex, 
    avg(sfe.salary+sbon) compensation 
from 
    sf_employee as sfe
    inner join sum_bon
    on sfe.id=sum_bon.worker_ref_id
group by 
    sum_bon.employee_title,
    sum_bon.sex