Zapytanie wybierz jeden rekord dla kategorii, SQL one record for category Opcje

[LowiczakPL]

.. jest tam zdanie jęśli nie został jeszcze załadowany

ja go zawsze ładuję jako proxy i mam do niego dostęp bez odwoływania się do bazy, czyli bez względu na to że mam relację

Kategoria -> Artykuł -> Autor artykuły - nazwisko autora

to ja mam to jako 1 zapytanie, nawet jak pobieram to w pętli jak sugerowałem na początku tego posta

Ten post edytował LowiczakPL 8.09.2021, 15:36:01

[nospor]

Ale jak to jedno zapytanie odpalasz w petli to masz juz x zapytan
Jak masz 10kategori to masz 10 zapytan.

A jesli wszystko ladujesz od razu jak tu chyba doczytalem, to juz w ogole autor pyta o 10 rekordow a ty z bazy pobierasz 1000. Temu to jest nadal nieoptymalne

[LowiczakPL]

Reasumując, dzięki tej naszej dyskusji zoptymalizowałem przez przypadek 16 zapytań do 4 czas mi spadł z 1.45 ms do 0.50 ms

a mój kod w pętli zwraca 47 obiektów ogłoszeń, ponieważ tyle mam kategorii, no i ani jednego zapytania o ogłoszenie wszystkie obiekty są pobierane z proxy dlatego, mam jeszcze 3 inne zapytania, nie związane z pętlą Encji Category

[PHP] pobierz, plaintext 
        foreach($allCategories as $category){
            dump($category->getClassifieds()->first());
        }
[PHP] pobierz, plaintext 

Query Metrics pokazuje:

4 Database Queries
0.50 ms Query time

[nospor]

No dobrze, jesli pobrales wszystko przed petla to nic dziwnego ze w petli ci nie leci juz do bazy. To tez ci pisalem.
Autor ma 1000 kategorii powiedzmy i dla kazdej chce pobrac po jednym artykule. Twoje rozwiazanie pobiera wszystkie kategorie i wszystkie artykuly za jednym zamachem mimo ze autor nadal potrzebuje tylko malego ulamka z tego. Tak, to jest nieoptymalne

Kolejna sprawa to twoje dane testowe. No sorki, ale 47 kategorii to nie jest baza testowa. Zrob z tego 1000 kategorii, kazda z 1000 artykulow i wtedy bedziesz widzial czy to dziala czy nie A najlepiej po 10000

[LowiczakPL]

w pętli to leciało i nadal jest to 1 zapytanie do bazy

jednak dla tej ilości kategorii czyli ponad 3k z ogłoszeniami -> zapytanie skoczyło do 27 ms,

obstawiam że jeśli chodzi o artykuły to max kilkanaście kategorii starczy

Ten post edytował LowiczakPL 8.09.2021, 16:44:07

[nospor]

Sorki, moze to przez to zycie, ale nie wierze ze mowimy o tym samym albo ze napewno wszystko poprawnie sprawdzasz.
Tak czy siak, sama petla bez magii wczesniej nie zadziala, a tej magii wczesniej nadal nie pokazales

ps: spadam offline. jak cos sprawdze jutro jesli cos nowego sie pojawi

[gornik]

Sprawdziłem z ciekawości bo akurat kodze sklepik który ma kategorie i produkty.
W kontrolerze wywołałem:

[PHP] pobierz, plaintext 
$em = $this->getDoctrine()->getManager();
        $categories = $em->getRepository(ProductCategory::Class)
            ->findBy(['isActive' => true]);
 
        foreach($categories as $category){
            $item = $category->getProducts()->first();
            if($item)
                echo "#{$item->getId()} <br />";
        }
[PHP] pobierz, plaintext 

Categories i products są powiązane relacją many to many
Wynik:
44 - Database Queries
86.60 ms - Query time

Następny test:

[PHP] pobierz, plaintext 
$em = $this->getDoctrine()->getManager();
 
        $products = $em->getRepository( Product::Class)
            ->findAll();
 
        foreach($products as $product){
            $image = $product->getImages()->first();
            dump($image);
        }
[PHP] pobierz, plaintext 

Tutaj już posiadam relacje produkt -> obrazki OneToMany->ManyToOne

Wynik:
37 - Database Queries
42.77 ms - Query time

Nospor ma rację.


Ten post edytował gornik 8.09.2021, 20:49:25

[LowiczakPL]

Twój test mówi tylko tyle że próbowałeś sprawdzić pewien stereotyp, który się potwierdził i nic więcej.

Dla mnie to tak jak pytanie się dwóch uczniów jak Wam poszło na klasówce

pierwszy odpowie bardzo słabo bo pomyliłem się w 3 zadaniach
drugi odpowie mi super, napisałem wszystko

Jesteś tym drugim uczniem, który wszystko napisałem poprawnie.

gornik, przecież nospor napisałem już to wcześniej że jeśli paczkę danych załadujesz przed pętlą to w pętli nie odwołujesz się do bazy.

W tym przypadku jest identycznie dane są w proxy i każdy obiekt w pętli jest zaciągany z proxy a nie z bazy, obojętnie jak głęboka to jest relacja

jest wykonane zapytanie z joinami, dane siedzą w proxy i z niego są zaciągane,

ma to sens w przypadku małej ilości danych, w tym poście było mowa o kategoriach artykułów, ja u siebie mam 4 kategorie artów, sprawdza się to super nie kombinuje z repozytoriami tylko odwołuje się w ten sposób

Ten post edytował LowiczakPL 9.09.2021, 07:05:42

[nospor]

ma to sens w przypadku małej ilości danych, w tym poście było mowa o kategoriach artykułów, ja u siebie mam 4 kategorie artów, sprawdza się to super nie kombinuje z repozytoriami tylko odwołuje się w ten sposób

No wlasnie. A ja zawsze zakladam ze mamy duza ilosc danych bo predzej czy pozniej jesli aplikacja wypali to te dane rosna i potem zonk. Dlatego nadal uwazam ze to jest nieoptymalne. Zgadza sie, przy malej ilosci danych nie zauwazysz problemu ale zawsze tak jest ze przy malej ilosci danych nigdy nie widac problemu

Raz robilem audyt dla firmy bo im jedna stronka sie odpalala 2minuty. Sie okazalo ze koles robil drzewko kategorii. Wczytywal wszystkie dane na raz, obrabial je, zaciagal dodatkowe dane itd... ale w danej chwili bylo potrzebne tylko mala czesc danych. Wszystko bylo fajnie jak bylo tylko pare kategorii... po paru latach aplikacja sie rozrosla, doszlo w pyte kategorii i krach. Dlatego ja jestem przeczulony by pisac aplikacje porzadnie od razu a nie "dziala" wiec dobrze.

[com]

@LowiczakPL tylko trzymanie danych całych obiektów w tym proxy dla 1000 rekordów nadal jest nieoptymalne(nawet z lazy loadingiem), ORMa używa się do Write Modelu, do Read modelu DBAL

Ten post edytował com 9.09.2021, 12:57:49

[LowiczakPL]

com, a czy to nie jest przypadkiem tak z ORM i DBAL

DBAL (DataBase Abstraction Layer) to oprogramowanie,
które upraszcza interakcję z bazami danych SQL,
umożliwiając korzystanie z nich bez martwienia się o specyficzne dialekty lub różnice między różnymi dostawcami DBMS.
Zasadniczo pozwala na uruchamianie zapytań SQL względem DBMS bez pisania SQL specyficznego dla dostawcy.

ORM (Object Relational Mapper) to narzędzie,
które daje wrażenie pracy ze strukturą danych w pamięci,
reprezentowaną jako graf obiektów z powiązanymi obiektami.
Upraszcza logikę aplikacji związaną z operacjami SQL poprzez usunięcie całego kodu SQL
i przekształcenie go w logikę OOP. Doctrine 2 ORM po prostu obsługuje ładowanie i utrzymywanie POPO (zwykłych starych obiektów PHP).

Ten post edytował LowiczakPL 10.09.2021, 05:39:13

[nospor]

Lowiczak my to wiemy. Ale wszystko z umiarem. A ty uzywasz Docrtine do pobrania calej bazy i trzymania jej w pamieci... Nadal nie rozumiesz jak zle to jest?

[Pyton_000]

Beton, beton widzę....

[com]

@LowiczakPL Operujesz na Doctrine wiec Ci dałem rozwiązanie w tym ekosystemie, ORM śledzi zmiany w Write Modelu dlatego tam się go używa, do odczytu danych nie potrzebujesz tego, w C# możesz sobie to wyłączyć o ile pamiętam, w Doctrine tego nie ma, w DBAL robisz RAW Query do bazy i wtedy ono jest wydajne, a jak zostawiasz to ORM, to on zrobi sobie pod spodem tyle zapytań ile uzna za stosowne i niekoniecznie tak optymalne jakby się chciało, bo to jest narzędzie uniwersalne, a nie najbardziej wydajne. Wiec tak jak @nospor napisał ORM Doctrine i wiele innych jest zbudowany na Doctrine DBAL uściślając, ale chodzi własnie o to żeby do Read Modelu używać RAW Query, gdzie samemu sobie wyciągasz to co potrzeba a nie dane całych obiektów do Proxy, by użyć tylko jednej kolumny z nich

Ten post edytował com 10.09.2021, 11:48:48