Стандарты форматирования SQL

Я использую Красный SQL ReFactor Логического элемента в SSMS, но другой инструмент, который делает переформатировать (и замена для SSMS) Редактирование SQL Вершины . Если Вы обращаетесь к почтовому индексу онлайн существует Простой Разговор SQL Prettifier .

Если я вношу изменения в уже записанный T-SQL, то я следую уже используемой конвенции (если существует один).

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

я думаю с SQL, форматирующим как с другими конвенциями формата кода, важный момент должен иметь конвенцию, не, что та конвенция (в областях здравого смысла, конечно!)

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

SELECT  st.column_name_1, jt.column_name_2,
        sjt.column_name_3
FROM    source_table AS st
        INNER JOIN join_table AS jt USING (source_table_id)
        INNER JOIN second_join_table AS sjt ON st.source_table_id = sjt.source_table_id
                AND jt.column_3 = sjt.column_4
WHERE   st.source_table_id = X
AND     jt.column_name_3 = Y

Короче говоря: добавление отступа с 8 пространствами, ключевые слова в ограничениях (хотя ТАК окрашивает их лучше, когда в нижнем регистре), никакой Camel-регистр (бессмысленный на Oracle), и строка переносятся при необходимости.

UPDATE:

UPDATE  target_table
SET     column_name_1 = @value,
        column_name_2 = @value2
WHERE   condition_1 = @test

И INSERT:

INSERT  INTO target_table (column_name_1, column_name_2,
                column_name_3)
VALUES  (@value1, @value2, @value3)

Теперь, позвольте мне быть первым, чтобы признать, что этот стиль имеет, это - проблемы. Отступ с 8 пространствами означает, что ORDER BY и GROUP BY или неправильно выровнять отступ, или откалывают Word BY отдельно. Также было бы более естественно расположить весь предикат с отступом WHERE пункт, но я обычно выравниваюсь следующий AND и OR операторы в левом поле. Расположение с отступом, после того, как обернуто INNER JOIN строки также несколько произвольно.

, Но по любой причине, я все еще нахожу легче читать, чем альтернативы.

я закончу с одним из своих более сложных созданий последнего использования этого стиля форматирования. В значительной степени все, с чем Вы встретились бы в SELECT оператор, обнаруживается в этом. (Это было также изменено для маскировки его источников, и у меня могут быть допущенные погрешности при этом.)

SELECT  term, student_id,
        CASE
            WHEN ((ft_credits > 0 AND credits >= ft_credits) OR (ft_hours_per_week > 3 AND hours_per_week >= ft_hours_per_week)) THEN 'F'
            ELSE 'P'
        END AS status
FROM    (
        SELECT  term, student_id,
                pm.credits AS ft_credits, pm.hours AS ft_hours_per_week,
                SUM(credits) AS credits, SUM(hours_per_week) AS hours_per_week
        FROM    (
                SELECT  e.term, e.student_id, NVL(o.credits, 0) credits,
                        CASE
                            WHEN NVL(o.weeks, 0) > 5 THEN (NVL(o.lect_hours, 0) + NVL(o.lab_hours, 0) + NVL(o.ext_hours, 0)) / NVL(o.weeks, 0)
                            ELSE 0
                        END AS hours_per_week
                FROM    enrollment AS e
                        INNER JOIN offering AS o USING (term, offering_id)
                        INNER JOIN program_enrollment AS pe ON e.student_id = pe.student_id AND e.term = pe.term AND e.offering_id = pe.offering_id
                WHERE   e.registration_code NOT IN ('A7', 'D0', 'WL')
                )
                INNER JOIN student_history AS sh USING (student_id)
                INNER JOIN program_major AS pm ON sh.major_code_1 = pm._major_code AND sh.division_code_1 = pm.division_code
        WHERE   sh.eff_term = (
                        SELECT  MAX(eff_term)
                        FROM    student_history AS shi
                        WHERE   sh.student_id = shi.student_id
                        AND     shi.eff_term <= term)
        GROUP   BY term, student_id, pm.credits, pm.hours
        )
ORDER   BY term, student_id

Это отвращение вычисляет, является ли студент полным рабочим днем или неполным рабочим днем в данном термине. Независимо от стиля, это трудно для чтения.

Да я вижу значение разметки Вашего sql некоторым строго определенным способом, но конечно соглашение о присвоении имен и Ваше намерение намного более важны. Как в 10 раз более важный.

На основе этого мои главные объекты неприязни являются таблицами, снабженными префиксом tbl и хранимыми процедурами, снабженными префиксом SP - мы знаем, что они - таблицы, и сверхзвуковое Именование объектов DB намного более важно, чем сколько пробелов, там

Просто моя ценность за 0,02$

Хороший. Как Python программист, вот мои предпочтения:

Новые строки после select, from и where только, когда это необходимо для удобочитаемости.

, Когда код может быть более компактным и одинаково читаемым, я обычно предпочитаю более компактную форму. Способность приспособить больше кода в одном экранном улучшает производительность.

select ST.ColumnName1, JT.ColumnName2, SJT.ColumnName3
from SourceTable ST
inner join JoinTable JT
    on JT.SourceTableID = ST.SourceTableID
inner join SecondJoinTable SJT
    on ST.SourceTableID = SJT.SourceTableID
    and JT.Column3 = SJT.Column4
where ST.SourceTableID = X and JT.ColumnName3 = Y

В конечном счете, это будет личным выбором, который будет сделан во время обзора кода.

Для insert, я поместил бы круглую скобку по-другому:

insert into TargetTable (
    ColumnName1,
    ColumnName2,
    ColumnName3)
values (
    @value1,
    @value2,
    @value3)

обоснование для этого форматирования состоит в том, что, если бы SQL использовал добавление отступа для блочной структуры (как Python), круглая скобка не была бы необходима. Так, если добавление отступа используется так или иначе, то круглая скобка должна иметь минимальный эффект на расположение. Это достигается путем размещения их в конце строк.

Я использую формат, подобный Вашему за исключением того, что я поместил ON ключевое слово на той же строке как соединение, и я поместил AND и OR операторы в конце строк так, чтобы все мое соединение/критерии выбора выстроилось в линию приятно.

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

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

SELECT
     my_column
FROM
     My_Table
WHERE
     my_id IN
     (
          SELECT
               my_id
          FROM
               Some_Other_Table
          WHERE
               some_other_column IN (1, 4, 7)
     )

операторы For CASE, я даю новую строку и добавление отступа для каждого WHEN и ELSE, и я выравниваюсь END назад к CASE:

CASE
     WHEN my_column = 1 THEN 'one'
     WHEN my_column = 2 THEN 'two'
     WHEN my_column = 3 THEN 'three'
     WHEN my_column = 4 THEN 'four'
     ELSE 'who knows'
END

Я склонен использовать расположение, подобное Вашему, хотя я даже иду несколько шагов вперед, например:

select
        ST.ColumnName1
    ,   JT.ColumnName2
    ,   SJT.ColumnName3
from
                SourceTable     ST

    inner join  JoinTable       JT
        on  JT.SourceTableID    =   ST.SourceTableID

    inner join  SecondJoinTable SJT
        on  ST.SourceTableID    =   SJT.SourceTableID

where
        ST.SourceTableID    =   X
    and JT.ColumnName3      =   Y
    and JT.Column3          =   SJT.Column4

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

Вы, вероятно, закончите со всеми видами ответов здесь. В конце это до персональных или согласованных командой предпочтений.

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

В целом, я понимаю, что все зависит от личных предпочтений, то, что работает для одних, не подходит для других.

Я работаю над написанием программы форматирования SQL с открытым исходным кодом (на данном этапе только для SQL Server) на C #, поэтому я пропустил через него вышеуказанные запросы.

Он использует стратегию, аналогичную OP, а именно, что каждый «раздел» имеет дочерние элементы с отступом под ним. При необходимости я добавляю пробелы между разделами для большей ясности - это не t быть добавленным, когда нет соединений или минимальных условий where.

Результат:

SELECT
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3

FROM SourceTable ST

INNER JOIN JoinTable JT
        ON JT.SourceTableID = ST.SourceTableID

INNER JOIN SecondJoinTable SJT
        ON ST.SourceTableID = SJT.SourceTableID
       AND ST.SourceTable2ID = SJT.SourceTable2ID

WHERE ST.SourceTableID = X
  AND JT.ColumnName3 = Y
  AND JT.Column3 = SJT.Column4

ORDER BY
    ST.ColumnName1