Formatowanie zapytań SQL

17

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?

GorillaApe
źródło
Sprzeciw może dotyczyć stosowania interpolowanych cudzysłowów (podwójnych cudzysłowów) i konkatenacji ( .), co widziałem, że niektórzy programiści ponoszą winę za koszty wydajności.
Bruce Alderson
3
Wszystko musi być na 1 linii? Witaj, pasek przewijania, czytelność do widzenia.
mike30
1
@BruceAlderson Brzmi jak jedna z tych pierwszych artykułów z 2000 roku, w których „gospodyni odkrywa 3 proste porady dotyczące optymalizacji swoich PHP”. Prawdziwa czerwona flaga z podwójnymi cudzysłowami i / lub konkatenacją pojawia się, gdy zaczynasz wstawiać zmienne bez właściwego ich unikania, tworząc ataki SQL injection.
Sean McSomething,
1
Czy do przetwarzania plików używane są jakieś „wewnętrzne” narzędzia?
Ian
Dlaczego tak trudno zrozumieć, że tak długo, jak zarabiasz na kodowaniu, odradzasz pisanie, czyszczenie, porządek, uporządkowanie kodu?
Tulains Córdova

Odpowiedzi:

33

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.

glasnt
źródło
5
Dobry pomysł, dzięki temu niewielka zmiana bardzo ładnie się wyróżnia w różnicach kontroli źródła.
Carson63000,
Prawie takie samo formatowanie, jakiego używam, chociaż zwykle umieszczam całą listę wyboru w jednym wierszu (lub w wielu wierszach, jeśli jest dużo kolumn)
Dean Harding
7
Podobny układ tutaj, jedyną różnicą jest przecinek wiodący, mamy go na końcu.
DBlackborough,
4
@ m.edmondson - Zróżnicowanie między wersjami w kontroli źródła podkreśla zmiany w poszczególnych liniach. W tym formacie każda linia zawiera jeden bit informacji - nazwę kolumny, nazwę tabeli, klauzulę łączenia lub zamówienia - co oznacza, że ​​diff wskaże dokładnie to, co się zmieniło, a nie tylko linię z wieloma rzeczami i cię opuści aby dowiedzieć się, co jest inne.
Jon Hopkins
2
Ten format ułatwia także komentowanie pojedynczych elementów podczas programowania oraz użycie wycinania i wklejania w celu zmiany kolejności.
Chris Nava,
14

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ć.

Blaszany Człowiek
źródło
3
Uzgodnione, wszystko sprowadza się do czytelności. Nie wpływa to w żaden sposób na wydajność itp. Wszystko jest po prostu estetyczne.
Christian
Zgadzam się, że wydajność nie może być dobrym argumentem.
Tin Man,
Nie wiem .. po prostu powiedział mi, żebym trzymał to w jednej linii, może dlatego, że tak
GorillaApe
Prawdopodobnie boją się go dotknąć, jeśli jest to „starszy” kod. Po prostu powoli wycofaj się i wszystko będzie dobrze.
Tin Man
Jego nowy kod ...
GorillaApe
8

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.

leed25d
źródło
6

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.

Bruce Alderson
źródło
1
W przypadku PHP nowdocsodmianą pojedynczą (tzn. Bez podstawiania zmiennych).
Alan Pearce
4

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.

Cthulhu
źródło
+1, a także rozważyłbym przekształcenie zapytania w procedurę składowaną
Larry Coleman
1

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 :)

heretik
źródło