Formatowanie zapytań SQL

Czy powinienem łamać zapytania SQL w różnych wierszach? Na przykład w projekcie, nad którym pracuję, mamy zapytanie, które zajmuje 1600 kolumn! 1600 znaków tabulatora. Napisałem takie zapytania:

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

Ale zażądali, żebym umieścił je w jednym wierszu i powiedzieli, że mój styl to złe formatowanie. Dlaczego to zła praktyka?

Ze względu na kontrolę źródła po każdej klauzuli where lub przecinku mamy podziały wierszy. Twoje powyższe zamienia się w

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

(tabulowanie i wyrównanie nie ma tutaj standardu, ale przecinki są zwykle wiodące)

Mimo to nie robi różnicy w wydajności.

Zapytanie składające się z 1600 kolumn brzmi, jakby wymagało poważnej weryfikacji przez dobrego DBA.

Jeśli zapytanie jest złożone, zawiń je. Jeśli jest to proste, zostawię to jako pojedynczą linię, chyba że będzie za długie, wtedy zacznę ponownie ją owijać.

Chodzi przede wszystkim o łatwość zarządzania i zrozumienie tego, co ma zrobić, więc o pakowaniu lub nie pakowaniu można decydować w locie, chyba że Twoja organizacja ma jakieś reguły formatowania kodu.

Re: to zła praktyka kodowania. Ledwie! To bardzo dobra praktyka. Nie ma dobrych powodów, dla których znam tak długie zapytanie, i wiele dobrych powodów, aby je sformatować. Jak powiedziałem wcześniej, wykwalifikowana DBA prawdopodobnie musi nad tym popracować.

Jedyną zaletą zapytań jednowierszowych, które przychodzą na myśl, jest to, że zapytania te mogą być nieco łatwiejsze do wyszukania. Poza tym jednak jestem zakłopotany. Osobiście wolę bardziej czytelne, podzielone zapytania.

Komentarze wielowierszowe są dobre, prawie niezbędne w przypadku dużych ilości SQL. A jeśli twój język programowania ma cytaty heredoc, jest jeszcze lepszy (ponieważ wielu edytorów może w nich wyróżnić składnię SQL).

Przykład:

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

Podczas pracy z zapytaniami zawierającymi dziesiątki linii (lub setek) zarówno wcięcie, jak i białe znaki sprawiają, że tekst jest wykonalny.

Wydaje się, że chodzi tu w szczególności o zdefiniowanie dużego zapytania w pewnego rodzaju języku programowania, widząc, że umieściłeś zapytanie w dosłownym łańcuchu znaków i połączyłeś je.

Jeśli jest to język skompilowany, nie powinno to mieć żadnego znaczenia - jedną z pierwszych optymalizacji, które wykonałby kompilator, jest automatyczne łączenie literałów łańcucha razem, więc i tak otrzymujesz duży ciąg.

Jeśli chodzi o składnię, powinieneś rozważyć przeniesienie zapytania poza kod - przechowuj je w osobnym pliku zasobów .sql i pozwól oprogramowaniu odczytać ten plik. Użyj przygotowanych instrukcji dla zmiennych, jeśli nie jest to zapytanie budowane dynamicznie (tzn. Dodawane klauzule where w zależności od określonych parametrów). Jeśli jest budowany dynamicznie, możesz dodać własne zmienne zastępcze, wstawiając dodatkowe parametry tam, gdzie jest to potrzebne.

Jeśli chodzi o 1600 kolumn, poważnie zalecam zbudowanie do tego widoku, więc zamiast

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

dostaniesz

WYBIERZ * Z widoku X GDZIE y

Znacznie bardziej zwięzłe we własnym kodzie.

Często używam formatu przedstawionego przez @glasnt do rozwiązywania skomplikowanych zapytań, jednak zwykle zapytania są w jednym wierszu.

To może nie odpowiedzieć na twoje pytanie, ale zdecydowanie sugeruję podzielenie zapytania na mniejsze zapytania. Oczywiście zależy to od zapytania, ale im więcej klauzul i złączeń dodasz do zapytania, tym mniej silnik SQL jest w stanie zoptymalizować zapytanie.

Twój dostawca bazy danych powinien mieć narzędzia takie jak EXPLAIN MySQL (lub ustawienie SHOWPLAN_ALL MSSQL), które pokażą ci, co baza danych robi za kulisami, aby zoptymalizować zapytanie, za każdym razem, gdy baza danych musi utworzyć tabelę tymczasową lub coś takiego, dodajesz ogromne opóźnienia, gdy mówisz o wielu równoczesnych użytkownikach.

Przenosząc coś, co może wydawać się trywialną logiką, z SQL do swojego kodu, możesz znacznie zwiększyć wydajność - SQL świetnie sprawdza się w prostych operacjach.

Oczywistą korzyścią, jaką może to dotyczyć, jest to, że zapytania są znacznie mniej złożone i łatwe do odczytania - łatwe do zarządzania (nie> 1600 kolumn) i szybsze. Zdecydowanie wszechstronne zwycięstwo.

Mam nadzieję że to pomoże :)