🚀 go-pugleaf

W dniu 2019-04-26 o 09:32, Wojciech Bancer pisze:

>> BTW
>> Jak tworzysz podkreślenia? Próbowałem _ przed i za, próbowałem __ i
>> kiszka. Być może więcej wyrazowych wyrażeniach próbowałem. Nie pamiętam już.
> 
> Przez dodanie _ na początku i na końcu wyrazu (bez spacji).

Sprawdzam:
_test_
_dwa wyrazy_
_dwa_wyrazy_
_dwa-wyrazy_

> Wygląda jak klasyczna niepotrzebna optymalizacja.
> Zamieniasz też " na ', żeby zyskać 2 sekundy czasu serwera w rok?

Nie, wcale nie 2 sekundy. Pisałem wcześniej, że przy ok pół miliona 
operacji (w ciągu nocy) udało mi się zaoszczędzić 2h pracy serwera 
(50%). Może nawet więcej. Nie pamiętam konkretnych liczb.

A cała sprawa wzięła się stąd, że gdy parę lat temu, gdy system był 
tworzony, nie przewidywano takiego sukcesu firmy. Informatycy wychodzili 
dokładnie z tego samego założenia co Ty, że dla tych 10k operacji nie 
będą "nadmiernie" optymalizować. A potem, zaledwie po kilku latach 
obudzili się z ręką w nocniku: ojej... system się nie wyrabia przy 500k. 
Mało tego... zaczęły zdarzać się upadki bazy bo Ci sami informatycy 
założyli, że im więcej RAMu przydzielą w Postgresie na proces, tym, 
lepiej. Rano ludzie przychodzą do pracy a tu nic nie działa bo na bazie 
trwają niesłychane prace lub w ogóle leży.

Gdyby Ci informatycy wzięli się za uczciwą robotę i nawet dla 
niewielkiego początkowo przedsięwzięcia postąpili zgodnie z kunsztem 
programowania zwracając uwagę na detale, to problem wystąpiłby dopiero 
po dojściu do możliwości serwera a nie możliwości kiepskich algorytmów.


> Wszysktie? Nie. Nadmiarowe, stworzone "na wszelki wypadek"? Tak.
> To co robisz nosi wszelkie znamiona premature optimization i unnecessary
> optimization. Niby jest wydajnej, ale różnicy nikt tak realnie nie zobaczy,
> a Ty tracisz na tym czas.

Czytaj powyżej.
Za moją "stratę czasu" dostałem niezłą kasę bo skończyły się w/w 
problemy. Argument kasy mnie przekonuje dodatkowo do słuszności podejścia.

Co do w/w optymalizacji, to faktycznie praca była mrówcza. Np. zamiast 
indeksować całe pole typu array() należało rozbić indeks na dwa: 
przeindeksować tylko część tablicy - bo okazało się, że zdecydowana 
większość zapytań właśnie o te części pytała. Podobnie było z 
zapytaniami SQL. Zamiast jakiejś tam konstrukcji zastosowano inną i znów 
progress wydajnościowy. Tymczasem od początku można było zrobić to 
dobrze...

Zarobiłem na partactwie innych... Gdyby mieli tam ORMa, to po zdobyciu 
jego podstaw... zacząłem mieć wątpliwości czy w ogóle dałoby się 
cokolwiek uratować w w/w projekcie.

> Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
> Jest narzędziem do budowania zapytań.
> Jak chciałbyś odpytywać bazę inaczej?

Raw SQL? Doctrine ma implementację czegoś takiego.

> Nie wszystko na bazie sprowadza się do robienia pojedynczych zapytań
> i działania na pojedynczych obiektach.
> 

Raw SQL ma JOINy od wieków.

> No nie. Query builder zbuduje zapytanie DQL:
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/dql-doctrine-query-language.html

...i baza to zrozumie? Nie sądzę. Zawsze na końcu będzie SQL. Resztę 
wypowiedzi dopiszę poniżej.


> 
> Uwalnie Ciebie od znajomości struktury (nazw kolumn kluczy, nazw tabeli),
> bo sam to ogarnia na podstawie otworzonej przez Ciebie relacji z obiektami
> Entities.
> 
> A potem ten DQL zostanie przetworzony na coś w stylu:
> DELETE FROM services s WHERE s.project_id = " . $project->getId(); // jeśli $project to obiekt
> DELETE FROM services s WHERE s.project_id = " . $project; // jeśli $project to prymityw (liczba lub string)

Czy to nie ja zadałem pytanie czy na wyjściu dostaniemy:
"DELETE FROM services s WHERE s.project=$project" ? :-D

Jakoś dostrzegam w tym podobieństwo :-D

> ale już bez Twojego udziału.
> Ale tak g gdzieś ostatecznie pod spodem jest wynik w postaci SQL.
> Przecież musi być, bazy danych inaczej nie gadają.

Właśnie! Kłopot jest jednak w tym, że zapytanie SQL jakie z tego się 
urodzi może (nie musi) wołać o pomstę do nieba. Tak jak to było przy 
UPDATE/DELETE. Nie twierdzę, bo jeszcze nie mam praktyki, ale flamastrem 
na tablicy napisałbym sobie tą rzecz jako wymagającą detalicznych 
obserwacji przy tworzeniu projektów by uniknąć wpadek.

> Zauważ, że:
>   - nie znasz tej nazwy tabeli (doctrine sam ją "ogarnia"
>     na podstawie tego jak zdefiniowałeś entity)
>   - do $project wstawiasz obiekt entity lub id, a doctrine
>     sam sobie poradzi z tym by to miało dla niego sens
>     sam też zna nazwę kolumny, na podstawie relacji jaka
>     była utworzona w entity

Tego nie musisz pisać. Ja to wiem i doceniam usprawnienie lecz w 
nielicznych / licznych / bardzo licznych przypadkach może stać się 
kamieniem u szyi.

Ja nie mogę powiedzieć klientowi: to nie ja spierniczyłem, to 
Querybuilder dodał gratisa od siebie w postaci mega-nieoptymalnej 
struktury. A indeksy w bazie? Po co to komu! Niech ORM sobie je ogarnia.

Jakbym dostał to takim komentarzu dyscyplinarkę, to wcale bym nie był 
zdziwiony.

-- 
Pozdrawiam,
Marek