Nieoptymalne wykorzystanie połączeń do bazy

[GoogleCodeExporter]

Być może czegoś nie rozumiem, ale wydaje mi się, że nowa klasa 
obsługująca połączenia do bazy poprzez PDO robi to w sposób mocno 
nieoptymalny.

Jeśli dobrze rozumiem, to gdy potrzebuję wykonać zapytanie, muszę stworzyć 
sobie obiekt klasy dataBase. Ten obiekt przy konstrukcji tworzy nowe 
połączenie do bazy danych, co nie jest optymalne, bo bardzo często 
wcześniej już takie połączenie zostało wcześniej otwarte. Każde otwarcie 
kolejnego połączenia to dodatkowy, niepotrzebny koszt. Przydałaby się 
statyczna metoda zwracająca połączenie (albo ewentualnie tzw. singleton).

Inną wadą (mniej istotną, ale jednak) jest to, że klasa umożliwia 
jednoczesne stworzenie tylko jednego kursora. Jeśli chciałbym wykonać dwa 
zapytania na raz, następnie sekwencyjnie przetwarzać ich wyniki, to muszę 
albo stworzyć dwa obiekty dataBase (czyli dwa połączenia do bazy danych), 
albo załadować wyniki obydwu zapytań do pamięci. Obydwie opcje są 
nieoptymalne.

BTW, jakiś czas temu postanowiliśmy, że trzymamy się PSR, a klasy wg reguł 
PSR powinny zaczynać się z dużych liter.

To nie ma dużego priorytetu niby, choć stosunkowo łatwo można to poprawić. 
Chyba, że czegoś nie rozumiem, wtedy proszę o wskazówki :)

Original issue reported on code.google.com by rygielski on 3 Dec 2014 at 8:02

[GoogleCodeExporter]

Mamy limit połączeń do bazy - czy przy takiej architekturze nie jest 
przypadkiem tak, że jeden skrypt PHP może wszystkie te połączenia zabrać 
dla siebie?

Bo jeśli np. korzystamy z N klas, a każda z nich ma własne połączenie, to 
wykorzystamy N połączeń jednocześnie. To by tłumaczyło dlaczego ostatnio 
musieliśmy ten limit połączeń zwiekszyć - poprzednia implementacja 
zjadała max 1 połączenie na jeden request, a nowa może ich zjeść - 
teoretycznie - nawet wszystkie.

Original comment by rygielski on 3 Dec 2014 at 8:11

[GoogleCodeExporter]

Niedawno też na to wpadłem :-)
przygotowałem dodatkowe opakowanie klasy w singletona, ale na razie jest w 
gałęzi medals - (możecie tam podejrzeć), ale z niedługo wrzucę -  w sumie 
mogę wrzucić już, bo wszystko co w tej gałęzi napisałem, oprócz klasy 
bazodanowej nie jest spięte z resztą systemu. 

Nie zmieniłem samej klasy w singletona, bo są miejsca, gdzie są używane 
równolegle dwie instancje. 

Na pracę bazy z dwoma różnymi wskaźnikami nie mam pomysłu. to by mogło 
rozwiżać problem istnienia gdzieś tam dwóch instancji. Jak byś to 
rozwiązał?

Original comment by wloczynutka on 3 Dec 2014 at 8:46

• Changed state: Accepted

[GoogleCodeExporter]

PS: dlaczego ładowanie wszystkich wyników do pamięci jest nieoptymalne? To 
zależy od ilości spodziewanych danych, ale to z czym mamy do czynienia w OC 
jest zazwyczaj leciutkie. No chyba ze ktoś pobierze bez limitu * from caches 
where 1 :)

Original comment by wloczynutka on 3 Dec 2014 at 8:53

[GoogleCodeExporter]

> Na pracę bazy z dwoma różnymi wskaźnikami nie mam pomysłu. to by mogło 
rozwiżać problem istnienia gdzieś tam dwóch instancji. Jak byś to 
rozwiązał?

Użyłbym czystego PDO. Metoda query zwraca kursor. Zdaje się, że wystarczy 
ją wykonać dwa razy i mamy dwa kursory, i nadal tylko jedno połączenie.

> PS: dlaczego ładowanie wszystkich wyników do pamięci jest nieoptymalne?

Bo zużywa więcej pamięci niż nieładowanie :) W przypadku małych zestawów 
danych faktycznie nie ma to znaczenia.

Original comment by rygielski on 3 Dec 2014 at 8:58

[GoogleCodeExporter]

Commituję szkielet takiej moim zdaniem optymalnej konstrukcji wraz z #179.

Original comment by rygielski on 3 Dec 2014 at 9:12