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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приклад:

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

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

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

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

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

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

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

ти отримаєш

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

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

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

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

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

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

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

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