2009-06-19 3 views
1

Вы помещаете разделители (запятые, или, или операторы) в передней части линии?Является ли сборщик первого формирования (SFF) с помощью SQL Code Formating легче читать/поддерживать?

Select Field1 
    , Field2 
    --, Field3 
From [some_table] as ST 
Inner Join [other_table] as OT 
    ON ST.PKID = OT.FKID 
Where [this] = [that] 
    and [one_other] > 53; 

Я думаю, что лучшая функция - помочь разоблачить важных операторов (И/ИЛИ). Как второстепенное преимущество, кажется, легче прокомментировать.

Не знаю, где я взял его на начальном этапе, но Андрей Новик упоминает его в «Transact-SQL User-Defined Function» (Слышал, что он говорит,. Получил книгу бесплатно и очень рекомендую)

+0

Обычно я отступаю, но пропустил его здесь. В Microsoft SQL Management Studio у меня установлена ​​моя вкладка в 4 пробела. Stackoverflow не нравится ключ табуляции. – JeffO

ответ

2

На моем рабочем месте (небольшая консалтинговая компания, около 10 разработчиков, специализирующаяся на Oracle), которая является то, что наша конвенция, а так:

SELECT 
    p.id pd_id 
, p.var_no 
, p.status 
, o.name operator 
, o.r_id 
, o.r_type 
, o.start_datetime 
, o.end_datetime 
--, p.id rd_id 
--, p.s_control 
, p.xml_data last_d_res_xml 
FROM schema_a.table_x p 
JOIN schema_b.table_y o ON p.id = o.pd_id 
WHERE p.some_id = 11 
ORDER BY pd_id DESC, end_datetime DESC NULLS FIRST 

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

+0

Тщательный ответ. – JeffO

1

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

2

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

4

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

select foo.bar, 
     baz.ban, 
     foobar.bazban 
    from foomatic foo 
    join bartastic bar on bar.id = foo.id 
    join anemone anem on anem.id = bar.id 
where foo.bar <> 1 and 
     baz.ban = 'foo' and 
     (
     anem.bear in ('a', 'b') or 
     anem.zoo is null 
     ) 
; 
+0

Вы должны использовать эту компоновку столбцов и по-прежнему размещать разделители. – JeffO

+0

Когда разделители впереди (в частности, запятые), они образуют свой собственный столбец - и это позволяет легко избежать проблем с запятой, отсутствовать проблемы с предложением ON и т. Д. –

2

«Легче комментировать» - если вы не хотите комментировать первый элемент.

Не имеет значения, находятся ли ваши разделители в начале или конце линии - всегда будет краевой кейс, в котором вы не можете применить критерий «легко прокомментировать».

И если вы смотрите на уровне оператора (И/ИЛИ), то легко закомментирована линия может:

  • Изменить значение запроса
  • Результата в синтаксической ошибке

в общем, для ИНЕКЕ, если это не все Анд, то я, как правило, гнездо:

WHERE 
    ColumnA = 1 AND 
    ColumnB = 2 AND 
    (
     ColumnC = 3 OR 
     ColumnD = 4 
    ) 

Это поможет вам обнаружить случаи краев (упомянутые выше), где вам нужно будет прокомментировать оператор или добавить условие «1 = 1» перед блоком комментариев.

+0

Хорошая точка на первом предмете. Я надеюсь, что комментирование строки изменит смысл. В вашем примере чаще возникает синтаксическая ошибка, если одна из строк была прокомментирована. – JeffO

+1

Дело в том, что вы никогда не сможете избежать этих странностей - и обычно вы создадите ошибки синтаксиса (к счастью). Но если у вас много нерегулярных применений AND и OR (опираясь на синтаксические правила), и вы прокомментируете строку, вы можете внезапно получить гораздо более ограничительное или гораздо более слабое предложение WHERE. –

1

Это стандарт при моей последней помолвке. Потребовалось некоторое время, чтобы привыкнуть к, теперь все остальное выглядит странно для меня :)

SELECT e.emp_id 
     ,e.emp_name 
     ,d.dept_name 
FROM emp e 
     ,dept d 
WHERE e.dept_id  = d.dept_id 
AND d.is_active  = 'Y' 
AND e.current_status = 'ACTIVE' 
AND (e.class IN ('x','y','z') 
     OR e.class_na = 'Y') 
ORDER BY e.emp_name 
     ,d.dept_name; 

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

0

Я предпочитаю разделение предложения SELECT.

Это выделяет важные части запроса. Сепаратор спереди или сзади имеет значение только сейчас в списке SELECT

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

Select 
    Field1 
    , Field2 
    --, Field3 
From 
    [some_table] as ST 
    Inner Join 
    [other_table] as OT ON ST.PKID = OT.FKID 
Where 
    [this] = [that] 
    and 
    [one_other] > 53; 


Select 
    Field1, 
    Field2 --, 
    --Field3 
From 
    [some_table] as ST 
    Inner Join 
    [other_table] as OT ON ST.PKID = OT.FKID 
Where 
    [this] = [that] 
    AND 
    [one_other] > 53; 
Смежные вопросы