Wiele zapytań SELECT vs zbiorcze Opcje

[hopsey]

Hej,

mam prośbę o analizę i opinię nt. rozwiązania, którego założeniem jest poprawienie szybkości pracy aplikacji przez ograniczenie wykonywanych zapytań do bazy danych.
Załóżmy taka sytuację - mamy listing produktów, przy każdym z produktów trzeba wyświetlić komentarze do produktu.

Produkty wyciągam np tak:

[PHP] pobierz, plaintext 
 $products = $tabela->fetchAll();
[PHP] pobierz, plaintext 

później w widoku mam foreach, komentarze wyciągam w taki sposób:

[PHP] pobierz, plaintext 
 
foreach($products as $product) {
    $komentarze = $products->getComments();
}
 
[PHP] pobierz, plaintext 

wywołanie metody getComments() powoduje wysłanie zapytania do bazy o komentarze do konkretnego produktu. w praktyce to wygląda tak, że dla 5000 produktów 5000 razy wykona się zapytanie do bazy. Oczywiście - wiem, że jest stronicowanie, ale chodzi mi o analizę sytuacji, dlatego w tym przykładzie z tego nie skorzystam

i teraz moje pytanie - czy nie lepiej byłoby przygotować sobie wcześniej w PHP te dane?
zabrać identyfikatory produktów w tablicę i wyciagnąć jednym zapytaniem korzystajac z IN(id1, id2, id3 ...) ?

[PHP] pobierz, plaintext 
 
$ids = array();
foreach($products as $product) {
  $ids[] = $product->getId();
}
 
$commentsByProductId = $tabela->findByProductIds($ids); // załóżmy, że komentarze są posortowane wg product_id
 
foreach($commentsByProductId as $productId => $comments) {
  foreach($comments as $comment) {
    if(array_key_exists($productId, $products)) {
      $products[$productId]->addComment($comment);
    }
  }
}
 
 
[PHP] pobierz, plaintext 

w efekcie mamy dwa zapytania - jedno o produkty, drugie o komentarze z klauzulą WHERE z IN z identyfikatorami 5000 produktów.

Czy to nam znacznie odciąża bazę danych? Czy warto stosować tego typu rozwiązania przy optymalizacji?

z góry dzięki za wszystkie opinie!

[nospor]

Pierwsze rozwiązanie to poroniony pomysł.... najgorsze co możesz zrobic to pierwsze rozwiązanie.
Drugie jest ok.

Możesz też pobierać jednym zapytaniem i produkty i komentarze. Ale to komplikuje sprawę przy stronicowaniu.

[hopsey]

dzięki za odpowiedź. Tego też się spodziewam

czy możemy jakoś mniej więcej wyjaśnić z czego to wynika? np. wywołanie pojedynczego zapytania do bazy kosztuje jakieś setne ułamki sekund i ten czas zyskujemy poprzez skupienie zapytań w jedno?

osobiście zawsze optymalizuję aplikację tam gdzie to możliwe na każdej płaszczyźnie (z DB na czele - np lazy load na Rowsecie z rozwiązaniem z tym w stylu przykładu nr 2 wyżej), jednak ostatnio przejąłem projekt, gdzie rozwiązań optymalizacyjnych, o zgrozo, jest nie więcej niż 0. Aplikacja będzie operować na bardzo dużym rozmiarze danych, stąd moje obawy.

[nospor]

czy możemy jakoś mniej więcej wyjaśnić z czego to wynika? np. wywołanie pojedynczego zapytania do bazy kosztuje jakieś setne ułamki sekund i ten czas zyskujemy poprzez skupienie zapytań w jedno?

Wykonaj sobie 5tys zapytań na raz w aplikacji php i sam zrozumiesz
Nawet jeśli przejdzie to przez stronicowanie i będzie to powiedzmy 30 zapytań, to nadal jest to niesamowity zbędny koszmar.