Ile zapytań SQL to dużo Opcje

[athabus]

Hej - na początku zaznaczę, że nie jestem zawodowym programistom, a raczej takim amatorej-hobbystom, który czasami wykorzystuje php do pracy zawodowej (siedzę w e-commerce, więc czasami przydają się takie umiętności do napisania jakichś rozwiązań automatyzujących pracę czy generujące różne treści pod seo itp).

Obecnie wdrażamy nowy sklep i jestem mocno zaskoczony ilością zapytań jakie takie skrypty generują do bazy danych. Pomijam już fakt, że firma, która nam wdraża obecnie skrypt zrobiła jakiś master fackup, to jednak przyjrzałem się gołemu skryptowi (Prestashop), który np. mając 10 produktów w koszyku i odświeżeniu potrafi wygenerować +250 zapytań. Oczywiście wiem z czego to wynika - takie skryptu muszą być maksymalnie elastyczne i przez to wszystko przechowują w bazach danych od statusów po wersje językowe, ale jednak rodzi się pytanie ile to jest racjonalna ilość zapytań.
Mam w swojej historii taki skrypt sklepu napisany jeszcze w Symfony 1.0, na którym działa w miarę duży jak na polskie warunki sklep i analogiczna strona wywołuje 6-10 zapytań - fakt było to rozwiązanie w 100% dedykowane, bo w tamtych czasach nie było jeszcze dobrych platform sklepowych, więc większość tabel atomowych ze statusami itp. siedzi w cachu pliku konfiguracyjnego itd.

Teraz pytanie czy te ilości zapytań w produktach OpenSource (np. Magento, Prestashop czy nawet Wordpress) to jest niechlujna architektura / brak optymalizacji czy po prostu dzisiejsze (rozbudowane) skrypty tak mają, bo stawia się na elastyczność kosztem optymalizacji?

[athabus]

Tak ORM na pewno się przykładają do tego problemu. Dla przykładu Doctrine, czasami potrafi niezbyt intuicyjnie zadziałać z przypadku niektórych relacji i np. pobierać dodatkowe obiekty bez potrzeby - twórcy Doctrine wyjaśniali dlaczego tka się dzieje i jak unikać itp., ale jednak sam się na to kiedyś naciąłem.
Obecnie piszę projekt który korzysta ze sporej liczby relacji w bazie (w sumie nic aż taki wielkiego, tylko relacje dosyć złożone i zagnieżdżone) i w ORM czasami trzeba się trochę nagimnastykować, żeby trywialna rzecz nie powodowała 50 zapytań - ale z drugiej strony jest to tylko kwestia nakładu pracy i chęci wgryzienia się w temat i da się różnymi mechanizmami liczbę zapytań ograniczyć. Z drugiej strony przyznam, że ostatnio sam się trochę w tej kwestii wyluzowałem i jak dana akcja w całokształcie generuje te kikadziesiąt zapytań z czego np połowa w to jakieś proste selecty w pętli, który nie obciążają zbytnio zasobów, to sobie odpuszczam, bo szkoda mi godziny czasu na rzeźbienie. Co innego gdy te zapytania zaczynają się realnie przekładać na obciążenie. No ale ja piszę zazwyczaj aplikacje wewnętrzne, albo pod relatywnie mały ruch więc mogę sobie na takie niedbalstwo pozwolić.

W gotowych rozwiązaniach niestety coraz częściej łatwo się wkopać w niezłą kupę i np. doinstalować niepozorną wtyczkę od WP, która w połączeniu z większą bazą artykułów potrafi nieźle dać się serwerowi we znaki, a autor nawet się nie zająknie w opisie o tej kwestii. Może po prostu to wynika z tego, że do programowania wchodzi młode pokolenie, które wychowało się na smartfonach o mocy obliczeniowej większej niż serwery hostingowe kiedyś ;-) Jednak jak ja zaczynałem naukę PHP to zasoby były droższe i bardziej się je szanowało. Teraz większym kosztem jest dodatkowy dzień pracy programisty niż roczny koszt utrzymania przyzwoitego vps zamiast hostingu współdzielonego.