🚀 go-pugleaf

W dniu 2019-04-23 o 19:10, Marek S pisze:
> W dniu 2019-04-23 o 15:18, ww pisze:
> 
> 3. Na koniec... z czystej ciekawości spytam: czy istnieje jakiś natywny 
> sposób dla ORMa aby usunąć/zaktualizować pole w jakimś rekordzie bez 
> niepotrzebnie generowanego SELECT'a?
> 
> Szukałem po Stack'u lecz wszędzie widziałem jedynie to, że ludzie 
> posługują się SQLem by wykonać DELETE FROM tabela WHERE id=5. ORM wymaga:
> 
> // tu wykonywany jest nadmiarowy select
> $user =$entityManager->find('Users', $id);
> $entityManager->remove($user);
> $entityManager->flush();

a QueryBuilder nie umożliwia 
$em->createQueryBuilder()->delete()->where() lub 
$em->createQueryBuilder()->update() ??

W dniu 2019-04-23 o 22:47, Wojciech Bancer pisze:

> Ale po co Ci ORM w takim razie?
> Może chcesz mieć coś w tym stylu:
> http://www.pomm-project.org/

Bardzo ciekawe rozwiązanie. Zainteresuję się nim.
Ale jest jeszcze jedna rzecz. Moją intencją jest biegłe opanowanie 
Doctrine z uwagi na to, że w pracy będzie mi to potrzebne. Realizacja 
jakiegoś własnego przedsięwzięcia w Doctrine + PostgreSQL + 
optymalizacja korzystania z bazy przez Doctrine, byłaby dla mnie cenną 
lekcją.

Tak, pamiętam Twoje słowa. Zamiast przyspieszyć 10x procesy w bazie, np. 
poprzez dołożenie triggerów odciążających ORM, czy przebudowanie/dodanie 
indeksów, wolisz postawić 10 serwerów. Ja preferuję inne podejście: 
zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się 
infrastrukturą sprzętową. Tego nie zmienię w sobie.

>> Nie rozumiem? Co to jest "coś" do Postgresa? Masz na myśli dedykowany
>> ORM? Nie da się Doctrine tak oprogramować, by korzystała z ficzerów
>> Postgresa?
> 
> Dać to się wszystko da, kwestia czasu i środków.
> Ale jak dotychczas chyba nie było zapotrzebowania, bo nic tego typu
> opensource nie powstało (albo nie zostało wystarczająco rozreklamowane).

Zostało rozreklamowane nie jeden raz. Ostatnio rowery trójmiejskie 
stanęły - to dobra reklama beztroskiego korzystania z wszelkich 
udogodnień przez programistów, bez wnikania, co de facto będzie działo 
się w tle. ORM ma to załatwić i już. A jak się coś sypnie, skończy się 
jakaś sekwencja bo za krótka była (ORM taką sobie wygenerował) etc... 
wtedy powstaje problem. Zanika rozumienie nawet prostych SQLi. Jak dla 
mnie to czarny scenariusz dla rozwoju. Nie działa - wyrzucamy i robimy 
kolejnego bubla.

> Doctrine ma kompatybilność jako cel nadrzędny, więc może jednak ten
> ORM nie jest dla Ciebie?

Tak jak napisałem powyżej - raczej muszę się go trzymać z uwagi na 
pojawiające się zadanie w najbliższej przyszłości. Im więcej będę 
potrafił wycisnąć z tego ORM, tym lepiej dla mnie. Opanowanie CRUD nie 
jest moim celem. Opanowanie Doctrine - już tak.

>> A mimo wszystko tenże ORM pozwala na użycie SQL'a w ramach własnych
>> struktur... Tyle tylko, że samemu trzeba te parę linijek kodu
>> niepotrzebnie dopisywać.
> 
> No to po co Ci ORM jak chcesz używać SQLa?

Ponieważ przyspiesza znacząco rozwój oprogramowania. Jeśli utworzę SQL, 
to nie oznacza to, że ORM nie będzie potrafił go wykorzystać w sposób 
zautomatyzowany. Przykład: obsługa zdarzeń ORMowych, którą mi sam 
zapodałeś.

> 
>>> Laravel ma dodatkową metodę statyczną Model::destroy($id).
>> No ale my o Doctrine... Z Laravelem już się pożegnałem.
> 
> Da się i w doctrine, z użyciem query buildera.
> https://stackoverflow.com/questions/15555042/doctrine-2-delete-with-query-builder (pierwsza odpowiedź)

To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz 
r=traktując go jako raka w ORMie.

> Można też użyć PartialObject / PartialReference:
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/partial-objects.html
(...)
 > Działa przy różnego rodzaju joinach, czy update, może zadziałać i tu.

Ok, to może mieć sens. Muszę to w głowie przekompilować.

-- 
Pozdrawiam,
Marek

W dniu 2019-04-24 o 08:24, ww pisze:

> a QueryBuilder nie umożliwia 
> $em->createQueryBuilder()->delete()->where() lub 
> $em->createQueryBuilder()->update() ??

Tak, to wiem. Ale jak sama nazwa wskazuje - Query... czyli programista 
generuje SQL. Alternatywnie jest też Native SQL - gdzie SQL jest już 
zupełnie jawny, bez zastępowania wyrażeń SQLowych odpowiednikami 
ORMowymi. QueryBuilder to taki trochę większy kamuflaż SQL'a. Może i 
racja, że to można nazwać natywnym sposobem.

Na uwadze miałem to, że Wojtek dość dobitnie podkreślał parę razy, że 
SQL w ORM, to delikatnie mówiąc: nietakt. A nawet, że gdy zajdzie 
potrzeba użycia SQL'a, to należy zrezygnować z ORM.

Stąd było moje pytanie.

-- 
Pozdrawiam,
Marek

On 2019-04-24, Marek S <precz@spamowi.com> wrote:

[...]

> Tak, pamiętam Twoje słowa. Zamiast przyspieszyć 10x procesy w bazie, np. 
> poprzez dołożenie triggerów odciążających ORM, czy przebudowanie/dodanie 
> indeksów, wolisz postawić 10 serwerów.

Nie, nie, nie, nie. Nie zrozumiałeś. To co napisałem to:
Zamiast przyspieszyć _moze_ 2x procesy w bazie np. przez dołożenie trigerów,
wolę mieć opcję stabilnej obsługi zarówno 10, 100 jak i 1000+ userów "na raz")
bez straty wydajności, w zależności od potrzeb, przez auto-skalowalne rozwiązania.

> Ja preferuję inne podejście: 
> zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się 
> infrastrukturą sprzętową. Tego nie zmienię w sobie.

No i właśnie. Projektujesz system który "ma ścianę" i to dość blisko.

>> Dać to się wszystko da, kwestia czasu i środków.
>> Ale jak dotychczas chyba nie było zapotrzebowania, bo nic tego typu
>> opensource nie powstało (albo nie zostało wystarczająco rozreklamowane).
>
> Zostało rozreklamowane nie jeden raz. Ostatnio rowery trójmiejskie 
> stanęły - to dobra reklama beztroskiego korzystania z wszelkich 
> udogodnień przez programistów, bez wnikania, co de facto będzie działo 
> się w tle.

Problem w tym, że na razie "beztroski" to wydajesz się Ty, w angażowaniu
ORMa bez zrozumienia idei za nim stojących.

> ORM ma to załatwić i już.

I nawet nie chciało Ci się zajrzeć do manuala tegoż ORMa, prawda?
Bo byś znalazł rozdziały dot. wydajności, batch processingu itp.

> A jak się coś sypnie, skończy się  jakaś sekwencja bo za krótka była 
> (ORM taką sobie wygenerował) etc... 

Znowu fałszujesz i nadinterpretowujesz sobie fakty ja Ci wygodnie.
ORM "sam" sobie nie generuje nic. Generuje to co mu każesz.

[...]

>> Da się i w doctrine, z użyciem query buildera.
>> https://stackoverflow.com/questions/15555042/doctrine-2-delete-with-query-builder (pierwsza odpowiedź)
>
> To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz 
> r=traktując go jako raka w ORMie.

Gdzie Ty tam widzisz SQL? o.O
To jest wg Ciebie SQL?
---
$qb = $em->createQueryBuilder();
$qb->delete('Services', 's');
$qb->where('s.project = :project');
$qb->setParameter('project', $project);
---

Ciekawe. Jaki dialekt wiesz może?
Rozróżnij też DQL od SQLa.

To że Doctrine pracuje na obiektach oraz ich modelach i relacjach (patrz wyżej, masz 
referencję do obiektów, nie do nazw tabel), nie oznacza że każdy jedne wiersz i linijka
musi być hydrowana.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 2019-04-24 o 20:01, Wojciech Bancer pisze:

> Nie, nie, nie, nie. Nie zrozumiałeś. To co napisałem to:
> Zamiast przyspieszyć _moze_ 2x procesy w bazie np. przez dołożenie trigerów,
> wolę mieć opcję stabilnej obsługi zarówno 10, 100 jak i 1000+ userów "na raz")
> bez straty wydajności, w zależności od potrzeb, przez auto-skalowalne rozwiązania.

Ok, czuję intencję.
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ż.

>> Ja preferuję inne podejście:
>> zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się
>> infrastrukturą sprzętową. Tego nie zmienię w sobie.
> 
> No i właśnie. Projektujesz system który "ma ścianę" i to dość blisko.

Czy jest coś w tym nagannego, że z wyciskam z serwera max. ilość 
operacji/s? Może inaczej: proponujesz pousuwać wszelkie optymalizacje z 
bazy, jak np. indeksy, po to by być daleko od ściany i mieć świadomość, 
że można dużo poprawić w tejże bazie?

> Problem w tym, że na razie "beztroski" to wydajesz się Ty, w angażowaniu
> ORMa bez zrozumienia idei za nim stojących.

Nie beztroski lecz uczący się. Jednakże już w tym wątku dostałem 
wytyczne jak "naprawić" ideę ORM w zakresie usuwania/aktualizacji 
rekordów poprzez banalnie proste zabiegi na udostępnionych przez ORM 
mechanizmach. Mam na myśli łatanie niedostatków poprzez stosowanie 
querybuildera etc.

> I nawet nie chciało Ci się zajrzeć do manuala tegoż ORMa, prawda?
> Bo byś znalazł rozdziały dot. wydajności, batch processingu itp.

Jestem w trakcie czytania dokumentacji. Na bieżąco pytam o to, czego nie 
rozumiem. Wyssałeś z palca moje podejście pomimo iż w poprzednich 
wątkach wyraźnie pisałem iż raczkuję dopiero i potrzebuję podpowiedzi. 
Otrzymałem, doczytam i wdrożę w testowym projekcie.

>> To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz
>> r=traktując go jako raka w ORMie.
> 
> Gdzie Ty tam widzisz SQL? o.O
> To jest wg Ciebie SQL?
> ---
> $qb = $em->createQueryBuilder();
> $qb->delete('Services', 's');
> $qb->where('s.project = :project');
> $qb->setParameter('project', $project);
> ---

Kompletnie nie znam querybuildera a widzę (być może fałszywie) to, co 
poniżej. Zgaduję, że Services odnosi się do nazwy entity a ta do tabeli 
o tej samej nazwie. Więc:

"DELETE FROM services s WHERE s.project=$project"

Czy źle odczytuję powyższe?

> Ciekawe. Jaki dialekt wiesz może?

Coś w rodzaju mowy od tyłu: niby słowa są znane... ale takie trochę inne.

Ale zgodziłem się już wcześniej, że jest to użyteczne narzędzie, które 
pozwoli mi na unikniecie kosztownych DELETE'ów. Oczywiście po zapoznaniu 
się wcześniejszym z batch processingiem. Bo być może to też będzie 
świetnym mechanizmem do optymalizacji zapytań hurtowych.

-- 
Pozdrawiam,
Marek

On 2019-04-25, Marek S <precz@spamowi.com> wrote:

>> Nie, nie, nie, nie. Nie zrozumiałeś. To co napisałem to:
>> Zamiast przyspieszyć _moze_ 2x procesy w bazie np. przez dołożenie trigerów,
>> wolę mieć opcję stabilnej obsługi zarówno 10, 100 jak i 1000+ userów "na raz")
>> bez straty wydajności, w zależności od potrzeb, przez auto-skalowalne rozwiązania.
>
> Ok, czuję intencję.
> 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).

>>> Ja preferuję inne podejście:
>>> zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się
>>> infrastrukturą sprzętową. Tego nie zmienię w sobie.
>> 
>> No i właśnie. Projektujesz system który "ma ścianę" i to dość blisko.
>
> Czy jest coś w tym nagannego, że z wyciskam z serwera max. ilość 
> operacji/s?

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

> Może inaczej: proponujesz pousuwać wszelkie optymalizacje z 
> bazy, jak np. indeksy, po to by być daleko od ściany i mieć świadomość, 
> że można dużo poprawić w tejże bazie?

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.

>> Problem w tym, że na razie "beztroski" to wydajesz się Ty, w angażowaniu
>> ORMa bez zrozumienia idei za nim stojących.
>
> Nie beztroski lecz uczący się. Jednakże już w tym wątku dostałem 
> wytyczne jak "naprawić" ideę ORM w zakresie usuwania/aktualizacji 
> rekordów poprzez banalnie proste zabiegi na udostępnionych przez ORM 
> mechanizmach. Mam na myśli łatanie niedostatków poprzez stosowanie 
> querybuildera etc.

Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
Jest narzędziem do budowania zapytań.
Jak chciałbyś odpytywać bazę inaczej?
Nie wszystko na bazie sprowadza się do robienia pojedynczych zapytań
i działania na pojedynczych obiektach.

>>> To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz
>>> r=traktując go jako raka w ORMie.
>> 
>> Gdzie Ty tam widzisz SQL? o.O
>> To jest wg Ciebie SQL?
>> ---
>> $qb = $em->createQueryBuilder();
>> $qb->delete('Services', 's');
>> $qb->where('s.project = :project');
>> $qb->setParameter('project', $project);
>> ---
>
> Kompletnie nie znam querybuildera a widzę (być może fałszywie) to, co 
> poniżej. Zgaduję, że Services odnosi się do nazwy entity a ta do tabeli 
> o tej samej nazwie. Więc:
>
> "DELETE FROM services s WHERE s.project=$project"

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

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)

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

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

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

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

On 2019-04-26, Marek S <precz@spamowi.com> wrote:

[...]

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

No nie obraż się, ale pokazujesz że nie masz na tyle ogólnej współczesnej
wiedzy odn. architektury systemów by obiektywnie ocenić gdzie optymalizacja 
mogłaby być najlepsza. Może masz rację, ale może nie. Może niekoniecznie 
optymalizacja powinna skupiać się na triggerach, może lepsze byłoby 
przemodelowanie procesu importu danych.

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

*Zaledwie* po kilku latach? Kilka lat w IT to przepaść.

No sorry, ale to brzmi jakby:
a) zrobili to co trzeba (wszystko działało prawidłowo przez kilka lat)
b) ktoś zarządzający w firmie "zapomniał" napomknąć / zainicjować zmiany
w aplikacji zanim zaczął się problem wydajnościowy. Albo nie przewidział
go.

> ojej... system się nie wyrabia przy 500k. 

A miał się wyrabiać przy pisaniu tej aplikacji?

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

Czyli Ci sami ludzie to programiści robiący za ekspertów DBA, 
administratorzy systemów i baz danych i co jeszcze? :)

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

A ja widzę typowe błędy zarządcze.
No ale idąc dalej, to jak myślisz, jak ktoś oceni Twoją pracę "za kilka
lat", jak firma rozwinie się jeszcze bardziej, dostawi się jeszcze
kilka maszyn i jednak wyjdzie, że optymalizacje które zrobiłeś teraz
już nie działają i mimo dostawienia maszyn system nadal się czka?

Ciekawe czy Twój następca wystawi Ci taką samą laurkę jak Ty swoim :)

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

Pisaliśmy o jednorazowym imporcie (i optymalizacji tego) a Ty płynnie
przeszedłeś do tłumaczenia że cały system był niewydajny "bo coś".

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

Rzecz w tym że "dobrze" ma więcej niż jedną postać.
I to jest przedmiotem dyskusji w tym wątku.

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

Czyli chcesz używać ORM bez zalet ORM i z wadami ORM. 
Fascynyjące :) Poczytaj o Unit of Work, o cache,
o tym jak się pracuje z obiektami:

https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/working-with-objects.html
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/caching.html

>> Nie wszystko na bazie sprowadza się do robienia pojedynczych zapytań
>> i działania na pojedynczych obiektach.
> Raw SQL ma JOINy od wieków.

I co z tego?

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

No to znowu, po co Ci ORM?

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

No to znowu, po co Ci ORM jak chcesz pisać SQLe?

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

Ale to *TY* spierniczasz bo nie rozumiesz narzędzia które używasz,
a starasz się go używać tak jakby go nie było i był czysty SQL.

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

Ja też.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 2019-04-28 o 14:50, Wojciech Bancer pisze:

>> 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.
> 
> No nie obraż się, ale pokazujesz że nie masz na tyle ogólnej współczesnej
> wiedzy odn. architektury systemów by obiektywnie ocenić gdzie optymalizacja
> mogłaby być najlepsza.

Ależ zgadzam się w 100%!

> Może masz rację, ale może nie. Może niekoniecznie
> optymalizacja powinna skupiać się na triggerach, może lepsze byłoby
> przemodelowanie procesu importu danych.

Przemodelowałem obie te rzeczy. Modyfikacja algorytmu importu też 
wniosła pozytywny wpływ, ale nie aż tak spektakularny.

Dobra, załóżmy, że jestem kretynem i metodą prób i błędów spowodowałem 
zaoszczędzenie czasu pracy serwera. Wpisywałem jedynie przypadkowe znaki 
z klawiatury. Po dwóch miliardach prób nawet zadziałało. Co z tego wynika?

>> ojej... system się nie wyrabia przy 500k.
> 
> A miał się wyrabiać przy pisaniu tej aplikacji?

Oczywiście, ze nie. Nikt nie zakładał tak dużego sukcesu firmy w 
pozyskiwaniu klientów.

I o to mi właśnie chodzi. Współczesny informatyk, wg Twojego opisu, to 
bezmózgi rzemieślnik, który jedynie jest w pełni świadom swoich 
niedomagań i w związku z tym implementuje byle jaki kod - aby tylko 
działał w trakcie testów i zaraz po uruchomieniu produkcyjnym. Chwilę 
potem może się walić... bo nie było w założeniach rzetelności jego 
pracy. Jeśli można napisać kod dobrze lub źle, nawet jeśli podobna ilość 
czasu jest na to potrzebna, to lecimy w wariant "źle".

Szerze mówiąc, przyznaję Ci rację w tym zakresie. Nierzadko przysłuchuję 
się rozmowom rekrutacyjnym i to jest niestety cechą frameworkowców. 
Czasem nie wiedzą czym protecetd różni się od public... To cytat z dziś.

>> 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.
> 
> A ja widzę typowe błędy zarządcze.

Bo kłopot jest w tym, że zarząd zwykle nie wie czym jest baza danych, 
API, PHP i inny informatyczny bełkot. Tu pełna zgoda. Jednakże nie 
bardzo znajduję w tym wszystkim preferowane przez Ciebie wykorzystywanie 
ich niewiedzy na rzecz własnego lenistwa.

> No ale idąc dalej, to jak myślisz, jak ktoś oceni Twoją pracę "za kilka
> lat", jak firma rozwinie się jeszcze bardziej, dostawi się jeszcze
> kilka maszyn i jednak wyjdzie, że optymalizacje które zrobiłeś teraz
> już nie działają i mimo dostawienia maszyn system nadal się czka?
> 
> Ciekawe czy Twój następca wystawi Ci taką samą laurkę jak Ty swoim :)

Zajebisty jesteś w tym momencie. :-D Zakładasz zatem, że dobrze napisana 
wyszukiwarka Google powinna działać na przydomowym serwerze. Mało tego, 
dostawienie Facebooka i Pinteresta też nie powinno wnieść istotnego 
obciążenia dla CPU :-D Aha... i łącze 1Mbps spokojnie wydoli.

A jak nie wydoli ... to będziemy pisać laurki na to, że jakiś kmiot 
informatyczny nie jest w stanie pchać przez łącze 1Mbps 10.000x tyle.

Tylko pogratulować takiego 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...
> 
> Rzecz w tym że "dobrze" ma więcej niż jedną postać.
> I to jest przedmiotem dyskusji w tym wątku.

Tyle tylko, że Ty wymagasz przekroczenia barier fizyki aby nie było 
beznadziejnie.

>>> 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.
> 
> Czyli chcesz używać ORM bez zalet ORM i z wadami ORM.
> Fascynyjące :) 

Próbujesz naginać teraz moje wypowiedzi do tego by pasowały do Twoich 
szyderstw. Ja planuję używać SQL do insertów/update'ów w sekcjach 
wymagających wydajności.

> Poczytaj o Unit of Work, o cache,
> o tym jak się pracuje z obiektami:

Sugerujesz, że są próby ratowania koncepcyjnej niedoróbki ORM w 
kolejnych segmentach Doctrine?

> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/working-with-objects.html
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/caching.html

Poczytam, ale nie wszystko na raz. Krok za krokiem przemierzam i testuję 
famework.

>> ...i baza to zrozumie? Nie sądzę. Zawsze na końcu będzie SQL. Resztę
>> wypowiedzi dopiszę poniżej.
> 
> No to znowu, po co Ci ORM?

Pisałem już: do wszystkiego, co nie musi być wydajne, bo jest za to 
wygodne. Np. zwykłe formularze fantastycznie proso się integruje z 
Doctrine. Ich wydajność może być tragiczna - nikt tego nie zauważy nawet.

> Ale to *TY* spierniczasz bo nie rozumiesz narzędzia które używasz,
> a starasz się go używać tak jakby go nie było i był czysty SQL.

Mam nadzieję, że doznam jakiegoś olśnienia i uznam, że 2 zapytania SQL 
(z czego wynik pierwszego jest ignorowany) są bardziej wydajne niż jedno.

-- 
Pozdrawiam,
Marek

On 2019-04-29, Marek S <precz@spamowi.com> wrote:

[...]

> I o to mi właśnie chodzi. Współczesny informatyk, wg Twojego opisu, to 

I tutaj stop. Nie wg mojego opisu. Twojego opisu, przeinaczonego z moich
słów. I w dodaktu nieudolnie. Nie chce mi się tego już kolejny raz 
prostować, ani w tym trybie dyskutować.

Mam wrażenie, ze nie przyszedłeś tu się uczyć czegokolwiek, tylko skrytykować 
podejście stosowane w danym frameworku/-ach i utwierdzać się w przekonaniu,
jak to Ty zajebiście postępujesz już od lat.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com