Dlaczego dodatkowe spacje i linebreaks w zapytaniach są złe?

Question

Widzę, od czasu do czasu, że ludzie mówią, że zapytanie SQL wysyłane do serwera z aplikacji klienckiej nie powinno zawierać żadnych dodatkowych linii lub spacji. Jednym z powodów, dla których słyszałem, jest "po co marnować ruch w sieci?".

Czy istnieje prawdziwy powód, aby kod był trudniejszy do odczytania i edycji na rzecz usuwania wszystkich spacji?

ze spacjami:

$q = 'SELECT 
      `po`.*, 
      `u`.`nickname`, 
      `u`.`login` 
     FROM 
      `postponed_operations` AS `po` 
      LEFT JOIN `users` AS `u` ON `u`.`id` = `po`.`user_id` 
     ORDER BY `will_be_deleted_after`'; 
return mysql_query($q); 

bez spacji:

$q = 'SELECT '. 
      '`po`.*,'. 
      '`u`.`nickname`,'. 
      '`u`.`login`'. 
     'FROM '. 
      '`postponed_operations` AS `po` '. 
      'LEFT JOIN `users` AS `u` ON `u`.`id`=`po`.`user_id` '. 
     'ORDER BY `will_be_deleted_after`'; 
return mysql_query($q); 

Answer 1

To prawda, będzie to kosztować ruch w sieci i czas serwera; ale będzie to nieistotne dla wszystkich, z wyjątkiem najbardziej skrajnych przypadków. Teraz, jeśli edytujesz kod FaceBook (lub Google, lub podobnego) i zoptymalizujesz w ten sposób 10 najczęściej używanych zapytań, to jest punkt, ponieważ będą one uruchamiane miliardy razy dziennie. Ale we wszystkich innych przypadkach uważam, że tracenie czasu na rozważanie usunięcia spacji jest stratą czasu.

Answer 2

To jest subiektywne, ale czytelność bije kilka dodatkowych spacji i podziały wierszy w każdej chwili w mojej opinii. A jeśli standardy kodowania będą dyktować przerwanie łańcucha za każdym razem, prawdopodobnie zwariowałbym.

Answer 3

Jeśli koniecznie musisz optymalizować miejsca i tym podobne miejsca, nie rób tego w swoim kodzie źródłowym. Zamiast tego przeprowadź zautomatyzowane narzędzie pośrednie.

Gdybyśmy mówili o sieci, powiedziałbym, że dodatkowe koszty w jej wykonaniu mogą być warte jej wartości statycznej (pliki skryptów, które rzadko się zmieniają itp.), Ale sceptycznie podchodzę do tego w przypadku zawartości dynamicznej.

We wszystkich przypadkach:

• W przypadku zmiany źródła, to będzie koszmar utrzymanie.
• Jeśli umieścisz to narzędzie kompresji/dekompresji, zaoszczędzisz znacznie więcej (średnio) niż po prostu usunięcie spacji, ale kosztem opóźnienia i czasu procesora.
• Chyba że masz jakąś naprawdę patologiczną strukturę, to w zasadzie stanowi niewielki ułamek w porównaniu do całkowitego kosztu, nawet jeśli rozważaliśmy tylko rozmiar pakietów TCP i zwróciliśmy dane zapytania.

Być może nie ma to znaczenia w twoim przypadku, ale wspomnę o tym w każdym razie: zupełnie inne podejście może polegać na użyciu ściśle zapełnionego formatu wiadomości zamiast identyfikatora zapytania, zamiast przesyłania zapytania za każdym razem.

Answer 4

Absolutnie. Robię to cały czas. Również:

• Usunąć cytaty. Kto ich potrzebuje?

Dlatego

`po` ----- becomes -----> po 

• stosowanie możliwie jak najmniejsza nazw baz danych, tabel, pól, indeksów itp

Dlatego

postponed_operations --- becomes ---> po --- p is already taken for posts 
will_be_deleted_after --- becomes ---> wi --- w is already taken for words 

• Całkowicie upuszczać niepotrzebne słowa kluczowe jak AS. Wszystkie nazwy tabel są krótkie i tak (! Reguła 2)

Dlatego

LEFT JOIN `users` AS `u` --- becomes ---> LEFT JOIN u 

W rezultacie, bym napisał powyższą kwerendę jako:

$q='SELECT po.*,ni,lo FROM po LEFT JOIN u ON i=ui ORDER BY wi' 

---

Tagi :

joke

Answer 5

Chociaż prawdą jest, że usunięcie niepotrzebnych spacji i podziałów linii zmniejszyłoby ilość danych wysyłanych do serwera bazy danych, ale nie powinieneś o to zapominać.

Raczej należy niepokoić o czytelność i łatwość konserwacji kodu. Oto dwie bardzo ważne rzeczy, o których musisz pamiętać podczas pisania kodu oprogramowania!

Jeśli zmniejszenie ruchu sieciowego była jedyną dobrą rzeczą, to możemy twierdzić, że należy dokonać Stored Procedure dla każdego zapytania, które piszesz.

Na przykład. Można zmienić następujące zapytanie

SELECT 
      `po`.*, 
      `u`.`nickname`, 
      `u`.`login` 
     FROM 
      `postponed_operations` AS `po` 
      LEFT JOIN `users` AS `u` ON `u`.`id` = `po`.`user_id` 
     ORDER BY `will_be_deleted_after`; 

do

CALL GetLoginData(); 

Teraz byłoby zmniejszenie ~ 80-95%. Ale czy warto?

Zdecydowanie nr

Robi takie rzeczy jak te raczej czynią życie deweloperów nieszczęśliwy bez dodawania żadnej znaczącej wartości!

Mając na uwadze powyższe, należy minified wersja kodu tylko w miejscach, gdzie nikt nie będzie zmiany kodu. Na przykład Biblioteki CSS i biblioteki JS, których nigdy nie zmienisz!

Mam nadzieję, że masz rację, i będziesz kontynuować pisanie czytelnego i konserwowalnego kodu!