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.

Według mnie PDO jest bardzo dobre

Nie musisz znać wszystkich funkcji do działania z różnymi bazami danych Wszystko się dzieje w konstruktorze

Uzywam pdo juz od dawna wiec sie wypowiem.


Spojny interfejs do wiekszosci baz danych nie chodzi o zadne dolanczanie sterowinika db/mysql.php czy niewiadomo jakie tam kosmosy sa. ODBC odpowiednie sterowniki baz danych wszystko to mialo byc zastapione przez PDO.


Nie spotkalem sie z tym i to nie prawda, pdo posiada bindowanie parametrow ktore temu zapobiegaja ale to trzeba samemu wywolac.


Tutaj bardziej mowa o zapytaniach DQL niz DDL przyklad Limit ORACLE nie posiada za to ma NUMROW, MySQL LIMIT x,y PG LIMIT OFSET. Cos takiego tylko Adodb wprowadzilo ale to nie jest pelna implementacja, bo bazki sie zmieniaja i rozbierznosci sa wielkie i nie kazdy producent trzyma sie standardu.



A co za problem napisac sobie takie cos do pdo.

Co do kodu to nie zauwazylem ze wiecej. Kwestia jak sie pisze kod.


Nieraz sa problemy choc ostatnio coraz wiecej problemow zostalo wyeliminowanych. Pouzywaj a sam sie przekonasz.

Interesuje mnie głównie MySQL i SQLite. Jest jeszcze inne rozwiązanie - przejść tylko na MySQL - wtedy nie ma problemu z kompatybilnością i nie trzeba nic kombinować.

Co powiecie o szybkości PDO oraz OOP? CMS aktualnie jest napisany w pełni proceduralnie. Obiekty mogę zastosować ewentualnie jedynie do bazy danych. Główne założenie CMS-a to szybkość.

Dołączanie pliku sterownika nie jest kłopotem. Gdy przejdę na PDO (obiektowe), nie będzie on pewnie potrzebny. Najgorsze jest to, że skrypt będzie miał jak na chwilę obecną zawyżone wymagania systemowe. Kolejny problem - poprawienie kodu pobierającego i wyświetlającego dane w plikach, które może zająć od kilku (gdy nie będzie problemów) do kilkunastu dni.

@WebCM A to zupelnie inny temat. Radze Ci przeczytac kilka ksiazek na ten temat.

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


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...


Wystarczy odpowiedni DSN.


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


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ść.


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.


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...):

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.

Stawiasz na szybkość.. bzdura, wg mnie jesteś po prostu amatorem, który myśli, że jak użyje jakieś funkcji zamiast obiektu to zoptymalizował aplikacje.

Nie wiem jak można ciągle patrzeć na przeszłość. Wydaje mi się, że niektórzy uważają się za jakieś guru i może powinni zastąpić programistów z zend bo wiedzą lepiej, że powinno się dalej używać funkcji do łączenia z bazą danych. Powodzenia.

Najgorsze, że zawyżę wymagania - PHP 5.

Powiedzmy, że funkcja db_read() wywołuje metodę lub funkcję odczytującą dane i dopisuje prefiks tabeli. Wtedy nie musiałbym robić gruntownych zmian. Jeśli wtedy w funkcji odwołam się do PDO, to zmienne obiektów będą globalne?

To by było chyba najlepsze rozwiązanie - obsługa proceduralnych metod - MySQL, SQLite i MySQLi oraz obiektowego PDO.

@WebCM Podobnie mysle jak sf i dodam slowa mika trzeba myslec a widze ze ty z tym masz problemy. Te rzeczy o ktorych piszesz byly walkowane wieki temu nie mowie tutaj o php ogolnie o OOP. O jakich globalnych mowisz, chyba stac cie na ksiazke do OOP przeczytanie i wysuniecia odpowiednich wnioskow.

OT Wlasnie przez takie posty psuje sie "smak" przebywania na tym forum.


---
Przenoszę na z PHP na Przedszkole.
~mike

Co jest złego w zmiennych globalnych? Jeśli nie używamy zmiennej poza funkcją, a nie chcemy stracić jej wartości, możemy zadeklarować ją słowem static. Nie przeczę, że OOP ułatwia pisanie skryptów, lecz wg mnie jest często nadużywane. Jak najbardziej można go użyć do komunikacji z bazą danych, choć używamy tylko 1. Wybór metody programowania logiki i struktury skryptu zależy od jej autorów. Jedni wolą pisać strukturalnie, a inni obiektowo. Obydwie metody są dobre.

OOP używam w JavaScript. Rolę klas mogą odgrywać funkcje. Tutaj obiekty zdecydowanie ułatwiają tworzenie - np. edytora tekstu (których może być kilka) ze względu na możliwość łatwej zmiany ich właściwości (np. pisać w BBCode czy HTML?) bądź AJAX. Każdy obiekt ma swoje parametry. Podobnie w programach - formularz, przyciski - to wszystko obiekty z odmiennymi właściwościami i zdarzeniami.

Wracając do tematu, dodatkowe sterowniki (PDO, MySQLi i SQLite - bo MySQL już istnieje) będą rozwiązaniem przejściowym. O dalszym ich losie zadecyduję później.

A ja ten wątek przeniosłem na Przedszkole, echh.
Trzeba było wywalić do kosza.
Proszę Cię ~WebCM nie pisz nic na temat OOP bo nie masz o tym zielonego pojęcia.
Nie zaniżaj poziomu merytorycznego forum.

Najlepiej będzie jak przeszukasz sobie forum i poczytasz co nieco na temat OOP (i na temat OOP vs. Procedural).