ďťż

[PHP] PDO - czy warto? Nowy interfejs baz danych

Podstrony

telcocafe

http://webcity.pl/we...miar_baz_danych

Czy warto zastosować PDO? Nie wszystkie serwery jeszcze posiadają PHP5. Aktualnie (2.06.2007) na DHost.info wciąż jest zainstalowana wersja 4.7, choć na forum jest umieszczona ankieta, czy dokonać aktualizacji.

Niektóre zalety
1. Prawdopodobnie nie trzeba dołączać pliku sterownika bazy danych (np. db/mysql.php)
2. PDO zabezpiecza zapytanie automatycznie przed SQL Injection
3. Obsługa wyjątków.
4. Ilość zaktualizowanych rekordów (np. po to, aby wyświetlić, czy operacja się udała).
5. Obsługa SQLite 3.

Niektóre wady
1. Więcej operacji + (prawdopodobnie) większe zużycie RAM.
2. Wciąż trzeba pisać niektóre zapytania osobno dla różnych typów baz (szczególnie CREATE TABLE).
3. Bardziej skomplikowany kod + więcej pisania = większy rozmiar plików?

Aktualnie stosuję do odczytu danych funkcję db_read() z 5 parametrami, która pobiera dane i zapisuje je od razu do tablicy numerycznej LUB asocjacyjnej BĄDŹ zmiennej (w zależności od 3 i 4 argumentu). Wystarczy podać nazwę tabeli bez prefiksu, wyciągane pola, nazwę tablicy/zmiennej, typ oraz warunek. Potem odczytuję dane z użyciem funkcji FOR. W przypadku przejścia na PDO trzeba będzie pisać pełne zapytania.

Może się okazać, że przesiadka na PDO sprawi tylko więcej problemów niż korzyści. Jeżeli macie już jakieś doświadczenia z tym interfejsem, wypowiedzcie się.

Dodane: czy funkcje klasy są kopiowane w pamięci RAM dla każdego obiektu?

Dodane 2: test PDO->__construct() vs. mysql_connect() i mysql_select_db() :: Tutaj nie ma wielkiej różnicy, ale pod Windowsem jest duża - utworzenie obiektu PDO jest kilka razy wolniejsze (nawet 100ms).
Użytkownik Ferrari edytował ten post 02 czerwiec 2007, 16:04

Odnośnie ankiety: 5.0 i 5.1 są porzucone, rozwijane jest jedynie 5.2 (poprawki bezpieczeństwa itp.)

1. Prawdopodobnie nie trzeba dołączać pliku sterownika bazy danych (np. db/mysql.php)
lol, w czym problem ?... w CI nawet bez PDO tego nie robię, robi to w tle kod frameworka bazując na konfiguracji

1. Więcej operacji + (prawdopodobnie) większe zużycie RAM.
głupoty

2. Wciąż trzeba pisać niektóre zapytania osobno dla różnych typów baz (szczególnie CREATE TABLE).
raczej większość. Zastosuj ORM bazujący na PDO i będziesz miał aplikację niezależną od typu bazy danych.

3. Bardziej skomplikowany kod + więcej pisania = większy rozmiar plików?
jeszcze większe głupoty. Plik PHP odczytywany jest lokalnie, dopiero wynik jego działania jest wysyłany. Rozmiar pliku, ilość komentarzy nie ma wpływu na szybkość całości.

1. W PHP6 pozostanie jedynie PDO i ewentualnie interfejsy MySQLi i SQLite. Stare zostaną przeniesione do PECL, gdzie zapewne szybko zdechną śmiercią naturalną.
2. PHP4 żyje do końca tego roku. Z końcem 2007 PHP4 zostanie porzucone - zero łat, zero nowych wydań. Kto nie zaktualizuje stanie się celem hackerów neostrady :P
3. Dla PDO istnieją rozszerzenia dodające obsługę dla bardziej kosmicznych baz jak Firebird czy DB2. Stare moduły są zazwyczaj porzucone.
Użytkownik Riklaunim edytował ten post 02 czerwiec 2007, 12:26
Czy nikt więcej nie ma doświadczenia z PDO i OOP? W PHP5 wydajność OOP została poprawiona. Gorzej w PHP4. Mam nadzieję, że w przyszłości OOP zostanie jeszcze bardziej zoptymalizowane.

Jeśli pisanie pod PHP4 już nie ma sensu, mogę pominąć tworzenie sterowników. Największym problemem w przypadku przejścia na obiektowy interfejs baz danych (MySQLi oraz PDO) jest potrzeba edycji większości plików CMS-a, a niektóre prawdopodobnie będę musiał przepisać. Jeżeli jednak PDO ma więcej zalet, prawdopodobnie go zastosuję. :)

Zaktualizowałem stronę testową. Pierwsze wywołanie jest najwolniejsze.
http://bugs.ugu.pl/testy.php
Użytkownik Ferrari edytował ten post 02 czerwiec 2007, 20:11
Tutaj wielu orłów nie znajdziesz. Zamiast "edycji większości plików" napisz skrypt od nowa :) mniej:
- irytujące
- czasochłonne
+ łatwiej wprowadzić nowe rozwiązania.

Możesz oszczędzić sobie zbędnej pracy http://framework.zen...l/pl/index.html - przykładowo mamy takie komponenty jak Zend_Db, Zend_Feed, Zend_Pdf, Zend_Search_Lucene, Zend_Validate... :)

jak coś testujesz tak na poważnie to z xdebugiem i na większych ilościach danych (gotowy kod z dużą ilością danych w bazie - kilka mega per tabela, by wykryć niezoptymalizowane zapytania)

Pominę już szybkość inicjacji (strukturalne MySQL bije strukturalne MySQLi i obiektowe PDO w moich testach) - czas jest podobny. Najgorsze, że po całkowitym przejściu na PDO zawyżę wymagania - PHP 5.

Dobrym wyjściem jest rozwiązanie pośrednie. Powiedzmy, że funkcja db_read() wywołuje metodę lub funkcję odczytującą dane i dopisuje prefiks tabeli. Wtedy nie musiałbym robić gruntownych zmian, a do pobrania rekordów bądź ich policzenia wystarczy wywołanie 1 funkcji. Jeśli wtedy w tej funkcji odwołam się do PDO, to zmienne obiektów (np. $stmt) będą globalne? Zalety - obsługa proceduralnych metod - MySQL, SQLite i MySQLi oraz obiektowego PDO. :)

z tobą to nie da się gadać :P Twoje "optymalizacje" i "testy" są g* warte bo w gotowym skrypcie (przy rozsądnej ilości danych) najwolniejszym etapem będzie wykonywanie zapytań czy operacje I/O na plikach. Zabawa "która funkcja jest szybsza" nie ma zupełnie sensu gdyż takie sprawy nie decydują o wydajności skryptu. Niezależnie czy użyjesz starego interfejsu czy PDO nie będzie to miało żadnego znaczenia. Znaczenie miałoby dopiero stosowanie dużej ilości śmietnikowych dodatków jak np. AdoDB, kosmiczne systemy skór itp. ;)

Popatrz na ten test a następnie ten - szybkie skrypty w pierwszym teście według drugiego wykonują znacznie mniej zapytań niż te wolniejsze (18 Fusion, 57 Postnuke). Gdy poprawiałem wspomniane wcześniej zapytanie SQL w PHP-Fusion czas ładowania widoku kategorii na localhoście spadł z 2.5 sekundy do 0,025 sekundy - 100 krotny wzrost wydajności :)

zawyżę wymagania - PHP 5.
Popatrz na ankietę ;) PHP4 istnieje do końca roku. Zrób to porządnie nie zwracając uwagi na nanosekund, inaczej nic tym skryptem nie osiągniesz.
Użytkownik Riklaunim edytował ten post 03 czerwiec 2007, 10:01
Jak już pisałem, różnicę szybkości tych metod pomijam, bo są podobne. :)

Jeśli PHP4 istnieje do końca roku, niektórzy mogą czekać rzeczywiście do 2008 z aktualizacją. Czy rozwiązanie z funkcją, która wywoła odpowiednie metody utworzonej klasy, jest dobre? (opisałem w poprzednim poście)

Wciąż istniałby sterownik z funkcjami db_read(), db_q(), itd... Później można by je przenieść już do jądra i używać PDO, gdy wszyscy przesiądą się na PHP5 i zostaną rozwiązane problemy, które mogą występować z tą biblioteką. Druga zaleta - mniej pisania kodu w plikach skryptu, gdyż funkcja w większości wypadku zrobi, co trzeba.

Na jednym z darmowych serwerów brakuje sterownika MySQL do PDO (nie wiem jak innych), zaś na płatnym przez pewien czas nie działał MySQLi. Hostingów z podobnymi ograniczeniami może być więcej.

Sprawność i stabilność interfejsów zależy również od konfiguracji serwera. Nie chciałbym się ograniczać wyłącznie do 1 metody - np. PDO bądź MySQLi ze względu na kompatybilność z hostingami oraz na to, że zamierzam wprowadzić SQLite.

Nazwy większości metod w SQLite, PDO, MySQLi są różne i mogą różnić się parametrami. Pozostaje mi pozostawienie plików sterowników z funkcjami bądź zastosowanie 1 interfejsu (PDO lub MySQLi). Zauważyłem wzrost wydajności przy użyciu pętli foreach do pobierania danych.
foreach( $stmt as $tablica ) { ... }
Czy SQLite 3 będzie obsługiwany również przy pomocy funkcji sqlite_* lub klasy SQLite, czy tylko przez PDO?
Użytkownik Ferrari edytował ten post 16 czerwiec 2007, 20:25

Na jednym z darmowych serwerów brakuje sterownika MySQL do PDO (nie wiem jak innych), zaś na płatnym przez pewien czas nie działał MySQLi. Hostingów z podobnymi ograniczeniami może być więcej.
Dlaczego płatne mają być w tyle? Jak płacę to wymagam, a jak odmawiają to zmieniam dostawcę i robię atyreklamę, proste :)

Sprawność i stabilność interfejsów zależy również od konfiguracji serwera. Nie chciałbym się ograniczać wyłącznie do 1 metody - np. PDO bądź MySQLi ze względu na to, że zamierzam wprowadzić SQLite.
PDO umożliwia obsługę zarówno SQLite jak i MySQLi

Nazwy większości metod w SQLite, PDO, MySQLi są różne i mogą różnić się parametrami.
Po to powstało PDO.

Najprawdopodobniej zastosuję PDO - ma chyba najlepszy zbiór metod ze wszystkich interfejsów oprócz długich nazw. Zacząłem już wcześniej przepisywanie kodu i chyba będę kontynuował. Dodatkowo napiszę emulator podstawowych funkcji tej biblioteki oparty o interfejs MySQLi, a może także o klasę SQLite. :) Czy to dobre rozwiązanie?

Nie robiłbym pewnie zmian, gdyby nie to, że dotychczas wyniki były buforowane, a podpinanie nie było możliwe.
Użytkownik Ferrari edytował ten post 17 czerwiec 2007, 07:38

Najprawdopodobniej zastosuję PDO - ma chyba najlepszy zbiór metod ze wszystkich interfejsów oprócz długich nazw. Zacząłem już wcześniej przepisywanie kodu i chyba będę kontynuował. Dodatkowo napiszę emulator podstawowych funkcji tej biblioteki oparty o interfejs MySQLi, a może także o klasę SQLite. :) Czy to dobre rozwiązanie?

Nie robiłbym pewnie zmian, gdyby nie to, że dotychczas wyniki były buforowane, a podpinanie nie było możliwe.

W sumie - użyj samo PDO - tak czy siak PDO przetrwa a pozostałe interfejsy będą "przestarzałe" w PHP6. Obecnie coraz szerzej będzie wchodziło PHP5 nawet na najbardziej hardcorowe serwery i PDO na pewno się na nich pojawi, a jak czegoś nie będzie to zawsze można wysłać mail do admina. PDO nie wymaga jakiś kosmosów, więc dodanie obsługi PDO to nie problem.

(...)a jak czegoś nie będzie to zawsze można wysłać mail do admina. PDO nie wymaga jakiś kosmosów, więc dodanie obsługi PDO to nie problem.

Uwierz mi że to jest problem dla adminów.
Czemu - nie wiem.
Na 5 serwerów do których wysłałem maila z prośbą o dodanie mysqli do php, żaden nie odpowiedział twierdząco.

Przepisuję obsługę bazy danych na PDO w skrypcie i przy okazji poprawiam potencjalne błędy XSS w formularzach. O emulatorze opartym o MySQLi pomyślę później, ale prawdopodobnie będę musiał go napisać ze względów ograniczeń niektórych serwerów.

Sposób na mniejszą objętość kodu (cyferki 2 i 3 wyjaśnię w pomocy):
$res=$db->fetch(2) #Asocjacyjna $res=$db->fetch(3) #Numeryczna $res=null; #Bez wywołania $res->closeCursor();

Sposób na mniejszą objętość kodu (cyferki 2 i 3 wyjaśnię w pomocy):
$res=$db->fetch(2) #Asocjacyjna $res=$db->fetch(3) #Numeryczna

Co za debilizm :P kod staje się niezrozumiały! To ci nic nie da a utrudni innym zrozumienie kodu. Niczego nie zyskujesz, a inni muszą poznać listę twoich skrótów (co robi 2 a co robi 3 :P) by zrozumieć o co chodzi w kodzie. na forum.php.pl napisali ci że nie masz pojęcia o programowaniu obiektowym i tworzeniu profesjonalnych aplikacji i to jest prawda. Zamiast tworzyć skrypt ty ciągle teoretyzujesz o jakiś abstrakcyjnych pomysłach i rozwiązaniach. Chcesz by twój skrypt konkurował z PHP-Fusion? możesz o tym zapomnieć, bo jedyną drogą konkurowania jest przedstawienie rozwiązania lepszego - bardziej elastycznego w modyfikacji kodu i wyglądu.

Sitedesign by AltusUmbrae.

Darmowy hosting zapewnia PRV.PL