witam,

chciałbym się poradzić, które rozwiązanie będzie korzystniejsze. nie chcę nic przeoczyć, a co dwie głowy to nie jedna:)

w moim serwisie zalogowany użytkownik może dodawać innych do ulubionych. chciałbym, żeby w zależności od tego czy dany użytkownik jest już dodany do ulubionych był widoczny link dodaj do ulubionych albo informacja, że ta osoba jest w ulubionych.
jak to sprawdzić?

ja mam w głowie 2 rozwiązania:
za każdym razem po wejściu na profil sprawdzać w bazie.
drugie rozwiązanie jest trochę bardziej skomplikowane, bo wymaga więcej operacji. podczas logowania pobierane są z bazy ID ulubionych użytkowników i zapisywane w sesji jako tablica. przy każdym wejściu na jakiś profil sprawdzana jest ta tablica z sesji. w przypadku gdy użytkownik zostanie dodany do ulubionych tablica ta musi zostać zmodyfikowana.

które rozwiązanie będzie lepsze jeżeli chodzi o wydajność? bo jeżeli mam patrzeć na łatwość implementacji to wybieram rozwiązanie pierwsze, dokładam tylko jedno zapytanie.

Odpowiedz sobie na pytanie: A jak często użytkownik będzie wchodził do profilu?

Pierwsze jest prostsze w implementacji i szybsze.

Dane sesji przecież są trzymane zazwyczaj na dysku lub w bazie, więc tak czy siak musi być wykonany odczyt.

Jakbyś chciał sobie odciążyć bazę to musiałbyś te dane w ciasteczkach trzymać, co IMHO jest bez sensu.

raczej często. a ma to jakieś znaczenie? przy każdym wejściu musi być wykonane dodatkowe jedno zapytanie lub przy drugim rozwiązaniu odczyt z pliku (z sesji).

Naprawdę nie masz co kombinować. Zakładając że tabela ma strukturę zawierającą dwa pola user_id, ulubiony_user_id to zapytanie jest tak mało zasobożerne, że nie widzę powodów dla szukania czegoś w zastępstwie. Nie wykonujesz żadnych złączeń, transfer między bazą a php jest znikomy, a warunek wyszukiwania operuje na indeksie. Wydaje mi się, że jakiekolwiek inne operacje potrwają dłużej.

skoro tak mówisz:)

a tak przy okazji, to ile zapytań jest powiedzmy w normie?
16 zapytań to nie jest lekka przesada?

Hmm, kwestia sporna, ale IMHO wydaje mi się, że trochę za dużo... To naprawdę zależy od tego, jakie zapytania wykonujesz i jak masz pozakładane indeksy.

To ie hydepark - przenosze na php
16 to norma

Moze w joomli...

16 może norma, ale widać, że za mało cache'ujesz.

jeszcze w Symfony nie doszedłem do tego jak robić cache dla pojedyńczych zapytań;) a całego widoku nie mogę zapisywać w cache bo dla każdego zalogowanego użytkownika może to wyglądać inaczej.

a w Joomli 16 zapytań to jest chyba wtedy gdy nie dorzuci się do niej więcej dodatków.

ja mam między innymi 6 zapytań, które tylko liczą, indeksy pozakładane na kolumnach z warunków.
zobaczymy w praktyce jak to będzie wyglądać:)

czasami takie 6 zapytan mozna zastapic jednym - zależy co liczą

tak, wiem o tym:)
ale gorzej jak są one porozrzucane w kilku miejscach aplikacji:)
czasem są wykonywane tylko 2, a czasem właśnie te 6. nie zawsze można je połączyć.
ale co się da to połączę:)
tylko zastanawiałem się czy rzeczywiście to wpłynie pozytywnie na wydajność.

np. 2 zapytania

[SQL] pobierz, plaintext 
SELECT count(idkontakt) FROM kontakt WHERE idprofil = 23
SELECT count(idulubione) FROM ulubione WHERE idprofil = 23
[SQL] pobierz, plaintext 

vs. jedno

[SQL] pobierz, plaintext 
SELECT (SELECT count(idkontakt) FROM kontakt WHERE idprofil = 23) AS kontakt, (SELECT count(idulubione) FROM ulubione WHERE idprofil = 23) AS ulubione
[SQL] pobierz, plaintext 

A stored procedures?

Tak.
Przy dwoch zapytaniach musisz doliczyc chociazby dwukrotny czas wyslania ządania do mysql i spowrotem. Przy jednym masz tylko jedno.
Akurat osobiscie twoje dwa zapytania zastąpilbym jednym union.