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

[WebCM]

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. Stawiam głównie na szybkość.

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. Więcej kodu PHP

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). Zwróćcie uwagę, że połączenie z bazą nie jest zamykane - dlatego proceduralna metoda jest tu wolniejsza. Gdy odwrócę kota ogonem, proceduralny sposób jest najszybszy.

[Ludvik]

Nie wszystkie serwery jeszcze posiadają PHP5.

PHP4 umiera, jedynym powodem do powstrzymania się przed aktualizacją jest kompatybilność z aplikacjami.

Stawiam głównie na szybkość.

Swego czasu, na łamach php solutions ukazał się artykuł porównujący interfejsy dostępu do baz danych. Nie chcę przesadzić, ale PDO plasowało się w czołówce. A że było to dawno, więc mogło się zmienić raczej na korzyść PDO...

1. Prawdopodobnie nie trzeba dołączać pliku sterownika bazy danych (np. db/mysql.php)

Wystarczy odpowiedni DSN.

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

Po pierwsze to jest hipoteza. Po drugie, nie sądzę, żeby te różnice były zbyt duże.

2. Wciąż trzeba pisać niektóre zapytania osobno dla różnych typów baz (szczególnie CREATE TABLE).

Przed tym to tylko uchroni ORM, który i tak będzie musiał do uwzględnić... Języka zapytań dla danego systemu nie przeskoczysz, nawet z pomocą PDO. Szczególnie, kiedy liczy się wydajność.

3. Więcej kodu PHP

To nie jest argument. Po pierwsze, nie zauważyłem specjalnie wzrostu ilości kodu po zastosowaniu PDO. Po drugie, ilość kodu nie przekłada się na wydajność. Po trzecie, dzięki wyjątkom i modelowi obiektowemu, PDO jest czytelniejsze i bezpieczniejsze w użyciu.

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.

Pięć parametrów nie sprawia wrażenia łatwo przyswajalnego kodu. Tak czy inaczej, ta funkcja skleja dane w zapytanie SQL, więc równie dobrze możesz wyprowadzić klasę pochodną z PDO i zrobić to samo.

Po zastosowaniu połączeń trwałych, różnice w wydajności są tak małe, że nawet nie warto o nich myśleć. Na twojej stronie ukazało mi się coś takiego (za 3 razem...):

Kod

Proceduralny: 0.684
PDO (pierwszy obiekt): 0.333
MySQLi obiektowy :0.3

10% na niekorzyść PDO przy takich rzędach wielkości nie jest warte zachodu.

Tak czy inaczej, żeby napisać system niewrażliwy na środowisko, musimy utworzyć jakiś interfejs dostępu do bazy. PDO jest dobrą podstawą do tego, w gruncie rzeczy jedyny problem to dostosowanie zapytań, ale to akurat wina po stronie producentów DBMS, a nie twórców PDO.