Форматування коду SQL-запитів


17

Чи слід ламати SQL запити в різних рядках? Наприклад, у проекті, над яким я працюю, у нас є запит, який займає 1600 стовпців! 1600 + символи вкладок. Я писав такі запити:

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

Але вони вимагали, щоб я вклав їх в один рядок, і сказали, що мій стиль - це поганий формат. Чому це погана практика?


Заперечення може бути у використанні інтерпольованих лапок (подвійних лапок) та конкатенації ( .), які я бачив, як деякі програмісти звинувачують у витратах на продуктивність.
Брюс Олдерсон

3
Все потрібно, щоб бути на 1 рядку? Привіт панель прокрутки, до побачення читати.
mike30

1
@BruceAlderson Здається, як один з тих початку 2000-х "Домогосподарка відкриває 3 прості поради щодо оптимізації вашого PHP". Справжній червоний прапор із подвійними лапками та / або конкатенацією виникає, коли ви починаєте вставляти змінні без належного уникнення їх, створюючи атаки ін'єкції SQL.
Шон Мак-Що-небудь

1
Чи використовуються які-небудь інструменти "вдома" для обробки файлів?
Ян

Чому так важко зрозуміти, що поки вам платять код, ви купуєте писати, чистити, акуратно, впорядковувати код?
Тулен Кордова

Відповіді:


33

З міркувань джерела, у нас є переривання рядків після кожного пункту або кома. Тож ваше вище перетворюється на

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(вкладка та вирівнювання тут не мають стандарту, але коси зазвичай є провідними)

Тим не менш, це не має різниці в роботі.


5
Хороша ідея, що це призведе до того, що невеликі зміни виділяться дуже непогано в розділі управління джерелом.
Carson63000

Приблизно такий самий формат, що і я, хоча я зазвичай розміщую весь список вибору в одному рядку (або декількох рядках, якщо є багато стовпців)
Дін Гардінг

7
Подібний макет тут, лише відмінність є провідною комою, ми маємо її в кінці.
DBlackborough

4
@ m.edmondson - відмінність між версією в керуванні джерелом виділяє зміни по черзі. У такому форматі кожен рядок містить один біт інформації - назву стовпця, ім'я таблиці, застереження про приєднання чи замовлення - це означає, що diff буде вказувати прямо на те, що змінилося, а не лише на рядок із багатьма речами та залишить вас щоб розібратися, що відрізняється.
Джон Хопкінс

2
Цей формат також дозволяє легко коментувати окремі елементи під час розробки та використовувати вирізати та вставляти для зміни замовлення.
Кріс Нава

14

Запит, який має 1600 стовпців, здається, що йому потрібен серйозний огляд хорошого DBA.

Якщо запит складний, я його завершу. Якщо це просто, я залишу його як єдиний рядок, якщо він не буде занадто довгим, тоді я почну обгортати його знову.

Вся справа в керованості та розумінні того, що вона повинна робити для обгортання чи не загортання, можна вирішити з ходу, якщо тільки ваша організація не має щодо цього правил форматування коду.

Re: це погана практика кодування. Навряд чи! Це дуже хороша практика. Я не знаю жодних вагомих причин використовувати такий запит, і багато вагомих причин переформатувати його. Як я вже говорив раніше, над цим, мабуть, потрібно попрацювати кваліфікованому DBA.


3
Погоджено, все дійсно зводиться до читабельності. Діяльність тощо не впливає на це зовсім, його все просто естетично.
Крістіан

Погодьтеся, що ефективність не може бути хорошим аргументом.
Олов'яний Людина

Я не знаю .. просто сказав мені тримати його в одному рядку, можливо, тому, що вони роблять
GorillaApe

Вони, мабуть, бояться торкнутися його, якщо це "застарілий" код. Просто повільно відступай і все буде добре.
Олов'яний чоловік

Його свіжий код ...
GorillaApe

8

Єдина перевага однопорядкових запитів, що спадає на думку, полягає в тому, що ці запити можуть бути дещо простішими для вирішення. Окрім цього, однак, я наткнувся. Особисто я віддаю перевагу більш читаним, розділеним запитам.


6

Мультилінійні коментарі хороші, майже життєво важливі при роботі з великими обсягами SQL. І якщо у вашій мові програмування є котирування heredoc, це ще краще (оскільки багато редакторів можуть виділити в них синтаксис SQL).

Приклад:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Під час роботи із запитами з десятків рядків (або сотень) і відступ, і пробіл роблять текст працездатним.


1
Для PHP тепер оператори - це одноцитований різновид (тобто відсутність заміни змінної).
Алан Пірс

4

Здається, мова йде саме про визначення великого запиту всередині мови програм програмування, бачачи, що ви ставите запит всередині рядкового літералу і об'єднуєте його.

Якщо мова йде про компільовану мову, вона взагалі не має значення - одна з перших оптимізацій, яку зробив би компілятор, - це автоматично об'єднати рядкові літерали разом, тож ви все одно закінчитеся з великим рядком.

Що стосується синтаксису, вам слід розглянути можливість переміщення запиту за межами вашого коду - збережіть його в окремому файлі ресурсу .sql і дозвольте програмі прочитати цей файл. Використовуйте підготовлені оператори для змінних, якщо це не запит, який будується динамічно (тобто, де додані пропозиції тощо додаються залежно від певних параметрів). Якщо він побудований динамічно, ви можете додати власні змінні змінні, вставляючи додаткові параметри, де і коли це потрібно.

Що стосується 1600 стовпців, я серйозно рекомендую побудувати вигляд для цього, тому замість цього

SELECT column1, column2, .... column1600 from X where Y

ти отримаєш

ВИБІР * ВІД viewX WHERE y

Набагато більш стисло у власному коді.


+1, і я також розглядаю можливість запиту в збережену процедуру
Ларрі Коулман

1

Я часто використовую формат, поданий @glasnt, для усунення складних запитів, однак зазвичай запити мають в одному рядку.

Це може не відповісти на ваше запитання, але я також настійно пропоную розбити ваш запит на менші запити. Очевидно, це залежить від запиту, але чим більше пропозицій та приєднань ви додасте до свого запиту - тим менше SQL-механізм здатний оптимізувати ваш запит.

У вашого постачальника бази даних повинні бути такі інструменти, як EXSLAIN MySQL (або налаштування SHOWPLAN_ALL MSSQL), які показуватимуть, що база даних робить за кадром, щоб оптимізувати ваш запит, кожен раз, коли база даних повинна створити тимчасову таблицю чи якусь подібну, ви додаєте величезні затримки, коли ви говорите про декількох одночасних користувачів.

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

Очевидною перевагою цього, як це може стосуватися вас, є те, що ваші запити набагато менш складні та легкі для читання - прості в управлінні (не> 1600 стовпців) та швидші. Визначально всебічний виграш.

Сподіваюся, це допомагає :)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.