SQL, кажется, самый забытый язык, когда дело доходит до форматирования красиво и с готовностью ... И поскольку SQL-заявления могут быть невероятно подробными и сложными, это делает его чрезвычайно с трудом работать. Но я нахожу, что когда я пытаюсь форматировать свой SQL-код наилучшим образом, я иногда не уверен, как это сделать. Я знаю стандарты для Java, C#, Python и т. Д., Но когда дело доходит до SQL, я не видел слишком много рекомендаций или принятых практик. Каковы советы/правила для форматирования SQL, чтобы они были ясными, четкими и логичными? Можете ли вы привести пример кода для иллюстрации? Что вы нашли наиболее стандартным, принятым способом форматирования SQL?Как убедиться, что мой код SQL не является страшным беспорядком
ответ
Вы можете попробовать проверить книгу Джо Селко SQL Programming Style. Я уверен, что есть много людей, которые не согласны с его стилем, но это хорошее начало.
Некоторые из моих собственных «правил»
- SQL ключевые слова всегда все прописные
- Имена таблиц «правильный» случай, в то время как столбцы и переменные в нижнем регистре
- Каждый " основным»оговорка в заявлении находится в начале строки
- JOIN и WHERE критерии появляются ниже и с отступом и выровнены
- Вложенные элементы с отступом дальше
- Я использую псевдонимы для всех таблиц и представлений
Например:
SELECT
column_1,
column_2,
CASE
WHEN column_5 = 'Blah' THEN 1
WHEN column_6 = 'Blah' THEN 2
ELSE 3
END AS column_alias
FROM
My_Table MT
INNER JOIN My_Other_Table MOT ON
MOT.column_1 = MT.column_1
WHERE
MT.column_2 = 'Some Value' AND
(
MT.column_3 = 'Some other value' OR
MT.column_4 = 'Some other value'
)
Похоже на меня, но у меня был бы INNER JOIN (без INNER!), Выровненный с таблицами (это не главное предложение) и условие в строке. В любом случае, этот общий макет - один из самых чистых, которые я видел. – gbn
Правда ... может быть, я постараюсь отступом от JOINs и посмотреть, как мне это нравится. Мне не нравится включать критерии только в одну строку, потому что часто может быть довольно длинным - и я ненавижу прокрутку влево/вправо. Я предпочитаю один критерий на каждой строке. –
Я бы начал отступать от критериев, если он был длинным, но держите его на одной строке, если он короткий: в частности, «JOIN table1 ON table1.table1_id = table2.table1_id» является наиболее распространенным случаем в течение длительного времени. Некоторое смещение postgresql здесь, так как это может быть написано «JOIN table1 USING (table1_id)», которое было бы глупо разделить. – araqnid
Я обычно следуют за этим типом синтаксиса для MSSQL Server
ВЫБОР statemenets
SELECT //optionally specify top or distinct
Field1,
Field2,
CASE WHEN (1 = 1) THEN
"1"
ELSE
"2"
END AS Field3,
...
FROM Table1 t1
INNER JOIN Table2 t2
ON t2.field1 = t1.field1 //I always reference the joined tables field name first
LEFT OUTER JOIN Table3 t3
ON (t3.field1 = t1.field1
AND t3.field2 = t2.field2) //I specify and with a new line and tabbed in
OR // I specify or(s) on thier own line this way you can distinguish from the two conditionals that need to be met
(t3.field1 = t2.field1
AND t3.field2 = t1.field2)
WHERE
(t1.Field1 = 'foo'
AND t1.field2 = 'bar')
OR
(t2.Field1 = 'foo'
AND t1.field2 = 'bar')
Производные таблицы в Select
Select
Field1,
Field2,
...
FROM (Select
Field1,
Field2,
Field3)
FROM Table1
WHERE
Field1 = '1') t1
Обновление отчетности
UPDATE Table1
SET
Field1 = 1,
Field2 = 2,
Field3 = 3
WHERE
(Field1 = 2
AND Field3 = 2)
OR
(Field3 = 1)
Вставка Заявления
INSERT INTO Table1
(Field1,
Field2,
Field3,
...)
VALUES
(1,
2,
3,
...)
Если отчётность
IF (some condition) BEGIN
END ELSE BEGIN
END
Процедуры
CREATE PROCEDURE Foo (
Bar INT,
Foo VARCHAR(20)
) AS
BEGIN
//Your Code Here
END
Я нахожу это невероятно подробным. Большинство баз данных не нуждаются в «INNER» или «OUTER» в синтаксисе соединения, а возврат строки для каждого критерия соединения - это пустая трата пространства, когда на экране есть ~ 80 символов. Использование этого формата является рискованным для динамического SQL, если вы не объединяете каждую строку с предложениями об открытии и завершении - по крайней мере на Oracle, потому что это пространство можно интерпретировать как интенсивные символы. –
Я рад, что вы упомянули сначала ссылку на имя поля объединенного стола. Однако без скобок логика AND/OR немного неоднозначна. –
@OMG Ponies. Да, я знаю, что вам не нужно использовать Inner and Outer, вы можете просто сказать JOIN вместо INNER JOIN и LEFT JOIN вместо LEFT OUTER JOIN. Это просто привычка, которую я сформировал. –
Я использую следующие правила:
- Всегда в верхнем регистре SQL зарезервированные слова (SELECT, FROM, WHERE, ИМЕЮЩИЕ И ИЛИ ИЛИ ОТКАЗЫВАЮТСЯ и т. Д.)
-
Гадкий:
select height,width,age from person where width = 20
Tidy:
SELECT height, width, age FROM person WHERE (width = 20)
Строчные имена всех таблиц. Никогда не используйте camelcase (donkeyWrench) в именах таблиц (вы будете стрелять в голову, если вы создадите запросы вручную).
Всегда используйте круглые скобки в предложениях WHERE и HAVING. Используйте пространство между операторами.
-
Гадкий:
... where width=20 and height>20
Tidy:
WHERE (width = 20) AND (height > 20)
- Используйте псевдонимы для tablenames.
-
`SELECT * FROM donkeywrench ВЕС ...`
- читаемые, связанные с TABLENAME поля первичного ключа. Я всегда запускаю ключи и первичные ключи с «id_».
-
имя_таблица: donkeywrench, первичный ключ: id_donkeywrench
- Марка, где запрос возник из. При чтении журналов вы можете легко отслеживать, где возникла проблема.
-
/* Вызывается из donkeykong.php, строка 22 * / SELECT * FROM donkeywrench ВЕС ...
- Если запрос займет слишком много
-
- Всегда оставляйте оператор (AND, OR) в конце строки
- Используйте круглые скобки!
Пример:
/*Executed from xyz.php*/
SELECT
p.height, p.width, p.age,
pd.hastel, pd.hasmobile
FROM
person p
LEFT JOIN personaldata pd ON p.id_person = pd.id_person
LEFT JOIN relatives r ON pd.id_person = r.id_person
WHERE
(p.width = 20) AND
((p.height > 20) AND (p.height < 15)) AND
(pd.hastel)
ORDER BY
p.age, p.height
Я не согласен с круглыми скобками вокруг условий WHERE. Когда приоритет оператора ясен, я нахожу его отвлекающим. Это как написать выражение ((x * y) + (s * t))/z вместо (x * y + s * t)/z. Когда число скобок меньше, легче видеть, как они совпадают. Конечно, это вопрос предпочтения. –
Может быть, это S "обман";) - но я только что нашел удивительный сайт, который делает это для вас!
И варианты полностью настраиваемый
Удивительный инструмент, и он бесплатный для загрузки! – svrist
Я, как правило, не писать SQL себя, чтобы избежать беспорядка ... – driis
Не новый предмет.Ознакомьтесь с http://stackoverflow.com/questions/118288/sql-coding-style-guide и другими с тегами кодирования и sql. –
Существуют стандарты для форматирования Java и C#? Распространяйте это слово, оно может, наконец, остановить бесконечные священные войны о стиле отскока и отступов. –