Są takie sytuacje gdy wymagane jest wykonanie szybkiego wsadu danych do tabeli. Oczywiście można na prędce stworzyć odpowiedni skrypt PhP, który przetworzy dane wsadowe do postaci zapytań SQL. Jednak nie zawsze ma to uzasadnienie i nie zawsze ilość czasu jest wystarczająca na stworzenie takiego mechanizmu.

Właśnie w takich sytuacjach przydatna może być kombinacja dwóch narzędzi: phpMyadmin i … to nie żart Ms Excel. Arkusz kalkulacyjny posłuży nam jako narzędzie do preparowania odpowiednio sformatowanego pliku CSV. Phpmyadmin posłuży nam natomiast do wykonania natychmiastowego wsadu do bazy.

Na potrzeby tego tutorialu stworzę wirtualną potrzebę wykonania wsadu do tabeli o poniższym wyglądzie

id_kw (int) AUTO_INCREMENT
name (varchar)
cond (int)

Jako wsad wykorzystany będzie plik xls zwierający kilkaset słów kluczowych.
W pierwszej kolejności wymagane jest odpowiednie sformatowanie pliku xls, do takiej postaci odzwierciedlającej strukturę tabeli. Pierwsza kolumna musi pozostać pusta – jest to kolumna odpowiadająca polu identyfikatora id_kw. W trzeciej kolumnie możemy dodać wartość początkową pola cond, lub pozostawić ją pustą w przypadku, gdy w strukturze tabeli określona jest wartość domyślna. Ja pozostawiam to pole puste.

Kolejnym etapem jest dodanie obrysu do wszystkich komórek arkusza odpowiadających wartościom pól tabeli. Zaznaczcie w Excelu „zawartość” tabeli a następnie zwykły obrys, efekt powinien być taki jak poniżej.

Na tym etapie może Was nieco dziwić to postępowanie jednak za chwilę zrozumiecie sens takiego działania. Zapiszcie bieżącą postać jako plik csv rozdzielany przecinkami (czytajcie uważnie pytania zadawane przez Excel i odpowiadajcie mądrze :D).

Otrzymany plik otwórzcie za pomocą jakiegoś edytora (najlepiej takiego który pozwala kontrolować kodowanie znaków). Pierwsze co pewnie zauważycie to fakt, że CSV rozdzielany przecinkami … jest rozdzielany średnikami (szczegół ). Obrysowanie dodatkowej pustej kolumny spowodowało, że po słowach kluczowych pojawił się dodatkowy średnik, który odpowiada polu cond.

Plik w obecnej postaci nie pozwoli Wam wykonać prawidłowego wsadu, jego kodowanie jest w ANSI. Przy bazie danych z kodowaniem UTF spowoduje oczywiście błędne wyświetlanie polskich krzaczków. Zmieńcie kodowanie znaków w pliku i zapiszcie go ponownie.

Przejdźmy teraz do phpMyadmina w którym wykonamy właściwy import danych. Wybierzcie odpowiednią tabele z bazy danych a następnie naciśnijcie zakładkę Import. W polu format wybierzcie CSV. Następnie musicie zmienić dolne opcje – Kolumny oddzielone: ustawcie ; . Pozostałe opcje możecie zostawić bez zmian. Naciśnijcie przycisk wykonaj … tabela zostanie wypełniona danymi. I gotowe … prawda, że szybko!

Zadanie robi się już nieco trudniejsze gdy przyjedzie Wam pracować z ciągami znaków wśród których znajdą się litery odpowiadające znakom diakretycznym charakterystycznym dla danego narodowego alfabetu. Użycie funkcji strtolower oraz lcfirst nie spowoduje że tego typu duże litery będą zamienione na małe. Znaki wykraczające poza zakres liter ‚alphabetic’ są pomijane przez te funkcję.

W takich sytuacjach z pomocą przyjdzie Wam funkcja mb_strtolower($string, $encoding) dostępna w ramach rozszerzenia Multibyte String Functions. Drugi (opcjonalny) argument tej funkcji określa kodowanie znaków konwertowanego ciągu znaków. Pozwala to na obsłużenie praktycznie każdego języka jaki jest obecnie używany w internecie. Warto dodać, że rozszerzenie to nie jest domyślnym rozszerzeniem PhP a co za tym idzie, nie każdy na każdym hostingu możliwe będzie skorzystanie z funkcji mb_strtolower().

W ramach uzupełnienia tematu dodam jeszcze mały tutorial z zakresu MySQL odpowiadający na pytanie: A co zrobić w przypadku, gdy to w bazie danych w jednej z kolumn tabeli mam ciąg znaków, który w trwały sposób chciałbym zamienić na wyrazy składające się tylko z małych liter. Oczywiście można tę operację wykonać po stronie PhP za pomocą funkcji wymienionych wyżej. Jednak znacznie bardziej optymalnym i szybszym rozwiązaniem będzie wykonanie tej operacji za pomocą pojedynczego zapytania UPDATE. Poniżej znajdziecie przykład tego typu zapytania SQL:
UPDATE `tabela` SET `nazwa_kolumny`=LOWER(`nazwa_kolumny`);
Po wykonaniu tego zapytania, we wszystkich rekordach w kolumnie `nazwa_kolumny` znajdą się ciągi znaków składające się tylko z małych liter.

Oczywiście wykonanie takiego zadania jest możliwe na poziomie odpowiedniej konfiguracji serwera. Jednak w przypadku zdecydowanej większości hostingów, zrealizowanie takiego zadania nie jest możliwe. W przypadku typowego wirtualnego hostingu jedynym sensownym rozwiązaniem jest wykorzystanie dobrodziejstwa pliku konfiguracyjnego .htaccess serwera Apache dla danego podkatalogu.

Poniżej znajdziecie odpowiedni kod dzięki któremu apache do każdego nagłówka określonego pliku doda deklarację wieku danego pliku:

<IfModule mod_headers.c>
 <FilesMatch "\.(jpg|jpeg|png|gif|swf|JPG)$">
 Header set Cache-Control "max-age=4838400, public"
 </FilesMatch>
 <FilesMatch "\.(css|js)$">
 Header set Cache-Control "max-age=4838400, private"
 </FilesMatch>
 </IfModule>

W zasobach internetu znajdziecie inne podobnego rodzaju rozwiązania, warto jednak zwrócić uwagę, że w przypadku plików typu css i js Cache-Control musi mieć atrybut Private a nie Public. W przeciwnym wypadku aplikacja PSI w dalszym ciągu będzie wykazywać Wam te pliki jako takie, które nie mają określonej żywotności.

Pewnie niektórzy z Was zrodzi się pytanie: Czy te zmiany mają wpływ tylko i wyłącznie na punktację w PSI?

Oczywiście wprowadzanie tych zmian tylko i wyłącznie w celu uzyskania lepszego wyniku nie ma większego sensu (poza satysfakcją). Zdecydowanie ważniejszą korzyścią jest to, że dzięki tym zmianom Apache instruuje przeglądarkę, aby w pierwszej kolejności starała się ładować pobierane zasoby z lokalnego dysku komputera użytkownika, a nie z sieci. Oczywiście przy pierwszym wywołaniu danego elementu (np. obrazka jpg) musi on zostać pobrany, jednak każde kolejne wywołanie tego elementu będzie powodowało odwołanie do pliku znajdującego się w cache przeglądarki. Zdecydowanie skraca to czas ładowania się stron, oraz zmniejsza ilość danych przesyłanych między serwerem a komputerem użytkownika.

A jak zmieniło to wynik uzyskiwany przez moją stronę w PSI? Poniżej znajdziecie zrzut:

Jak widać naprawdę niezły skok :).

W pliku css możliwe jest to za pomocą @fotn-face. W przypadku większości przeglądarek wystarczający jest plik TTF, niestety Internet Explorer jest tu wyjątkiem wymagającym specjalnego traktowania. Od wersji 6 do wersji 8 operacja ta obsługiwana jest za pomocą pliku z EOT (Embedded OpenType).

Dosyć dużym problemem jest wygenerowanie prawidłowo działającego pliku EOT. Teoretycznie pomoc powinno stanowić narzędzie WEFT dostarczane przez Microsoft. Niestety program ten jest bardzo stary i w większości wypadków mówiąc delikatnie działa mało zadowalająco (bardzo często zawiesza się oraz wypuszcza nieprawidłowe pliki). Obecnie jedynym w pełni działającym narzędziem (jakie znalazłem) umożliwiającym utworzenie sprawnego pliku EOT jest konwerter online dostępny pod wskazanym adresem:
http://www.kirsle.net/wizards/ttf2eot.cgi

IE9 wnosi kolejną zmianę do obsługi ładowanych czcionek. W tej wersji przeglądarki obsługa opiera się na nowym formacie plików WOFF (Web Open Font Format) opracowanym przez W3C. Najprawdopodobniej w przyszłości będzie to ogólny standard przyjęty przez wszystkie popularne przeglądarki.

Stosowanie @font-face w pliku CSS, wymaga bardzo starannej deklaracji, szczególnie istotna jest kolejność formatów plików. Poniżej znajdziecie prawidłową kolejność, która powinna działać poprawnie na wszystkich popularnych przeglądarkach (również mobilnych):

@font-face {
font-family: ‚MyWebFont';
src: url(‚/katalog/nazwaPliku.eot’);
src: url(‚/katalog/nazwaPliku.eot?#iefix’) format(‚embedded-opentype’),
url(‚/katalog/nazwaPliku.woff’) format(‚woff’),
url(‚/katalog/nazwaPliku.TTF’)  format(‚truetype’)
font-weight: normal;
font-style: normal;
}

Pewnie w tym momencie zaświecą się oczy wielu osobom, które chciały by ukryć w ten sposób arkusz stylów przed „przeciętnymi” użytkownikami. Niestety muszę ostudzić Wasz zapał, gdyż ta metoda linkowania ma również jedną bardzo dużą wadę dyskwalifikującą ją z powszechnego użycia … w tej chwili metoda ta jest obsługiwana jedynie przez Operę i Firefoxa.

W dalszym ciągu tego sposobu ładowania pliku CSS można użyć jeśli chcemy dodać „spersonalizowane” style dla przeglądarek obsługujących tę metodę linkowania. Na chwilę obecną to chyba jedne sensowne zastosowanie dla tej metody.

SELECT COUNT(*), DATE_FORMAT(date,'%Y-%m') as y_m FROM `page` GROUP BY y_m ORDER BY y_m DESC

Zapytanie to operuje na tabeli o następującej strukturze:

id_page (int 6)
title (varchar 32)
content (text)
date (datetime)

Zwrócony wynik będzie mieć następującą postać:

y_m liczba

2013-07 10
2013-06 5
2013-05 12

Powyższe zapytanie wykorzystuję funkcję DATE_FORMAT(), która pozwala na sformatowanie daty wedle określonych kryteriów. W tym przypadku wykorzystałem format %Y – rok w postaci 4 cyfr, %m – miesiąc w postaci 2 cyfr. Dodatkowo wykonane jest pogrupowanie oraz zliczenie rekordów dla tak zwróconej daty wpisu.

Jednym z popularnych zadań jakie może realizować GD to konwersja tekstu do pliku graficznego. Poniżej znajdziecie przykładowy listing w którym przestawiam realizację takiej operacji. Oczywiście należy potraktować ten kod bardziej jako przykład możliwości niż samo rozwiązanie tego zagadnienia.

<?php
header('Content-Type: image/png');

imagepng($im);
imagedestroy($im);
?>

Omawianie początkowego kodu zawierającego definicję tekstów poddawanych konwersji pomijam, właściwe wykorzystanie GD2 rozpoczyna się na etapie tworzenia zasobu zawierającego obrazek. Za działanie to odpowiada funkcja: imagecreatetruecolor(). Argumenty tej funkcji to szerokość oraz wysokość utworzonego obrazka. Funkcja zwraca identyfikator zasobu lub „false” w przypadku błędnego działania. Utworzony obrazek będzie miał założone wymiary oraz zostanie wypełniony czarnym kolorem.

W kolejnym kroku definiowane są kolory przypisane do utworzonego obrazka. Operację tę realizuje funkcja imagecolorallocate(resource $image , int $red , int $green , int $blue ). Argumenty tej funkcji to: $image – identyfikator zasobu, $red – poziom wartości koloru czerwonego 0-255, $blue – poziom wartości koloru niebieskiego 0-255, $green – poziom wartości koloru zielonego 0-255. Jeśli zależy Wam aby przypisany kolor odpowiadał konkretnej barwie, to w celu uzyskania wartości jego składowych w przestrzeni barw RGB, najlepiej skorzystać z jednego z programów graficznych (GIMP, Photoshop) lub innego narzędzia, gdzie możecie podejrzeć te wartości.

Tak jak pisałem wcześniej, utworzony obrazek będzie w całości wypełniony czarnym kolorem. Korzystając w funkcji imagefilledrectangle() wypełnimy go w całości białym kolorem. Funkcja ta ma następujące argumenty: resource $image – identyfikator zasobu , int $x1 – wartość współrzędnej x punktu początkowego , int $y1 – wartość współrzędnej y punktu początkowego  , int $x2 – wartość współrzędnej x punktu końcowego, int $y2  – wartość współrzędnej y punktu końcowego, int $color – identyfikator koloru wykorzystanego do wypełnienia. Warto zwrócić uwagę, że wartości współrzędnych punktu początkowego i końcowego operują od 0, co oznacza że w przypadku naszego obrazka zakres wartości x mieści się w przedziale <0,99> a współrzędnej y w przedziale <0,29>.

Kolejna operacja jaką musimy wykonać, to podanie miejsca w którym znajdują się kroje czcionek jakie chcemy wykorzystać przy pomocy biblioteki GD2. Za wykonanie tej operacji odpowiada funkcja putenv('GDFONTPATH=' . realpath('.')). Wynikiem działania tej funkcji jest przypisanie danej wartości do zmiennej środowiskowej serwera. Warto zauważyć, że wykonane działanie ma jedynie zasięg lokalny i jest widoczne jedynie dla danego skryptu PHP w którym funkcja została użyta. W naszym przypadku do zmiennej środowiskowej GDFONTPATH została przypisana wartość funkcji realpath('.'), czyli ścieżka do bieżącego katalogu w którym znajduje się skrypt. W przypadku, gdy plik z krojem czcionki znajduje się w innym katalogu, musicie wskazać poprawny adres do właściwego  katalogu.

W kolejnym kroku utworzymy cień do napisu. Budując tego typu obrazki musicie rozdzielić je na poszczególne warstwy składowe, które będą tworzone w odpowiedniej kolejności. Cień znajduje się nad tłem ale pod finalnym tekstem, więc musi być on utworzony między tymi warstwami.

Do transformacji tekstu na obraz posłużymy się funkcją imagettftext(). Funkcja ta ma następujące argumenty: $image – identyfikator zasobu , $size – wielkość textu , $angle – kąt pod jakim tekst będzie pisany , $x – wartość współrzędnej x początkowego punktu , $y – wartość współrzędnej y punktu , $color  – identyfikator koloru, $fontfile – ścieżka do pliku z krojem czcionki , $text – tekst przeznaczony do konwersji. W celu uzyskania bardziej rzeczywistego wyglądu cienia, stosując funkcję imagefilter($im, IMG_FILTER_SMOOTH, 1) – wykonamy rozmycie obrazka. Oczywiście rozmycie będzie dotyczyły bieżącego stanu w jakim znajduje się grafika, zastosowanie filtru nie ma wpływu na kolejne warstwy i efekty stosowane na dany obrazek.

Korzystając znów z funkcji imagettftext() dodamy właściwy tekst, który będzie przesunięty o 2 piksele w górę i w lewo w stosunku do cienia. W ostatnim kroku z uzyskanego zasobu $im uzyskamy finalny obrazek w postaci PNG. Działanie to realizowane jest za pośrednictwem polecenia imagepng($im). Na samym końcu niszczymy utworzony zasób $im – imagedestroy($im).

Wywołanie w przeglądarce pliku zawierającego powyższy kod, spowoduje wyświetlenie się utworzonego obrazka. Warto zauważyć, że w przypadku gdy nie prześlemy w nagłówku informacji o formacie pliku – header('Content-Type: image/png'); – po wywołaniu pliku w w oknie przeglądarki plik będzie prezentowany jako plik tekstowy a nie plik graficzny. Mam nadzieję że zachęciłem Was do nauki i zabawy z biblioteką GD2.

Poniżej znajdziecie najprostszą postać zapytanie z LEFT JOIN:

SELECT * FROM t1 LEFT JOIN t2 ON (column1)

Wynik tego zapytania zwrócony przez bazę danych to lista rekordów z pełnymi danymi oraz takimi w których część pól jest równa NULL. Lista obejmuje więc rekordy występujące w obu tabelach oraz w tabeli t1. Właściwością MySQL którą chciałem opisać jest to, że w przypadku takich zapytań dodanie warunku WHERE na kolumnie, która zawiera wartości NULL spowoduje usunięcie również tych rekordów w których dane pole jest równe NULL.

SELECT * FROM t1 LEFT JOIN t2 ON (column1) WHERE t2.column2 NOT LIKE 'clause';

Wykonanie powyższego zapytania uszczupli zwrócone wyniki nie tylko o te spełniające warunek WHERE, ale również usunie wszystkie rekordy w których przypadku wartość t2.column2 jest NULL. Taki sposób działania bazy danych nieco mnie zaskoczył. Osobiście oczekiwałem, że w wyniku działania warunku WHERE otrzymam listę zawierającą również te rekordy które występowały jednostronnie.

Jedynym sensownym rozwiązaniem w takim przypadku jest dodanie dodatkowego warunku zdefiniowanego w następujący sposób:

SELECT * FROM t1 LEFT JOIN t2 ON (column1) WHERE t2.column2 NOT LIKE 'clause' OR t2.column2 IS NULL';

Kolejny raz potwierdza się to, że baza MySQL traktuje NULL dosyć wyjątkowo, więc lepiej uważać jeśli jesteście zmuszeni programować zapytania na tabelach (lub wynikach zapytań), które będą zwracać rekordy zawierające takie wartości.

Przykład

Od jakiegoś czasu bardzo chętnie stosuję tę funkcję. Muszę przyznać, że jest ona wygodna i znacznie ułatwia implementację eksportu danych do pliku. Poniżej znajdziecie przykładowy kod PHP w którym wykonano prosty eksport danych pozyskanych z bazy MySQL do pliku CSV, który ma być wykorzystywany w programach z pakietu MS Office.

$usersRes = $pdo->query('SELECT * FROM `user`');
$users = $usersRes->fetchAll(PDO::FETCH_ASSOC);

$data = array();
$data[0]['id_user'] = 'Id';
$data[0]['f_name'] = 'Imię';
$data[0]['s_name'] = 'Nazwisko';
$data[0]['email'] = 'Email';
$data[0]['city_c'] = 'Miejscowość';
$data[0]['post_c'] = 'Kod pocztowy';
$data[0]['phone_c'] = 'Telefon';
$data[0]['add_date'] = 'Data rejestracji';

$datas = array_merge($data,$users);

foreach($datas as $key => $data){
foreach($data as $key_s => $single_data){
$datas[$key][$key_s] = iconv("UTF-8","cp1250", $single_data);
}
}

$filename = 'users.csv';

$FileHandle = fopen($filename, 'w+') or die("can't open file");

foreach($datas as $key => $data) {
fputcsv($FileHandle, $data, ';', '"');
}

fclose($FileHandle);


Omówienie kodu

Idąc od góry – pobranie danych za pomocą PDO w postaci tablicy asocjacyjnej. Utworzenie tablicy $data zawierającej nagłówek dla tabeli. Złączenie tablicy (array_merge) z nagłówkami kolumn z tablicą z danymi. Kolejnym ważnym krokiem jest konwersja kodowania w pozyskanych danych w celu prawidłowego wyświetlania danych w programach uruchamianych w Windowsie. W pętli pojedyncze pola rekordów konwertowane są na kodowanie cp1250 (właściwe dla MS Windows). W dalszej części tworzony jest uchwyt do podanego pliku csv (w+ – wskaźnik ustawiany na początku pliku, jeśli plik nie istnieje to będzie podjęta próba stworzenia go). Ostatnia część kodu odpowiada za wsad danych do pliku. I tyle :).

Bardzo szybkie i efektywne rozwiązanie wszelkiego rodzaju eksportów danych. Oczywiście można powyższy kod jeszcze uprościć, np dokonywać konwersji znaków na poziomie bazy danych (wykonanie zapytania: SET NAMES CP1250; przed właściwym zapytaniem pozyskującym dane) … ale takie zmiany pozostawiam już w Waszych rękach.

Od wersji PHP 5.5.0 tworzenie nowego kodu wykorzystującego rozszerzenie Mysql nie jest zalecane. Co więcej rozszerzenie to uzyskało status „deprecated” i (prawdopodobnie) zgodnie z zapowiedzią w dalekiej nieoznaczonej przyszłości zostanie usunięte. Jeśli w dalszym ciągu korzystasz z funkcji takich jak mysql_connect i mysql_query to chyba najwyższy czas abyś zaczął korzystać z biblioteki PDO. Od wersji PHP 5.1 jest ona nowym integralnym interfejsem przeznaczonym do obsługi komunikacji z bazą danych. Specjalnie nie piszę z jakiego typu bazą danych gdyż jedną z wielkich zalet tego interfejsu jest jego uniwersalność. PDO daje możliwość podłączenia się z praktycznie każdą popularną bazą danych obecną na naszym rynku, warto wspomnieć choćby o takich bazach danych jak: MySQL, MS SQL, Oracle, PostgreSQL, SQLite.

Rozwinięcie skrótu PDO, czyli PHP Data Objects, od razu sugeruje nam (zgodnie z prawdą), że interfejs ten jest w pełni OOP. Połączenie z bazą definiowane jest już na etapie tworzenia obiektu klasy PDO. Przykładowy kod prezentujący taką akcję znajdziecie poniżej:

define("DBHOST", "nazwa.hosta.pl");
define("DBNAME", "nazwa_bazy");
define("USER", "nazwa_uzytkownika");
define("PASS", "haslo_uzytkownika");

try {
$dsn = "mysql:host=" . DBHOST . "; dbname=".DBNAME ;
$pdo = new PDO($dsn,USER,PASS);
} catch (PDOException $e) {
print $komunikat;
}

Oczywiście nie musicie trzymać się takiej konwencji. Jeśli nie chcecie korzystać ze stałych, nic nie stoi na przeszkodzie by zamienić je na zmienne. Warto zwrócic uwagę na pierwszy paramtr $dsn. W zmiennej tej zawarty jest skrót nazwy bazy danych (DSN – Data Source Name) wykorzystanej jako źródło danych. W zależności od typu bazy danych wykorzystywany jest odpowiedni sterownik niezbędny do wykonania połączenia z dana bazą. Przykładowe skróty DSN popularnych baz danych znajdziecie poniżej:

sqlsrv – MS SQL, Azure
pgsql – PostgreSQL
mysql – MySQL
oci – Oracle
sqlite – SQLite

Ważne jest przechwycenie wyjątku przy podłączeniu, gdyż domyślny komunikat o błędzie wygenerowany przez PHP ujawni nazwę użytkownika oraz nazwę bazy, co nie jest zbyt pożądanym rozwiązaniem. Warto by w takich wypadkach pojawiał się zdefiniowany przez nas własny komunikat.

Wykonywanie zapytań PDO.

Wykonanie zapytań SQL jest bardzo proste i wymaga jedynie wywołania odpowiedniej metody utworzonego obiektu PDO. Poniższy kod prezentuje pobranie danych z tabeli:

$usersRes = $pdo->query('SELECT * FROM `user`');
$usersCount = $usersRes->rowCount();
$users = $usersRes->fetchAll(PDO::FETCH_ASSOC);

Wykonanie metody query spowoduje utworzenie nowego obiektu klasy PDOStatement. W powyższym przykładzie wykorzystano dwie metody z tej klasy: rowCount(), oraz fetchAll(). Pierwszy z nich pozwala uzyskać liczbę wierszy zwróconych przez zapytanie (w przypadku zapytań typu INSERT, UPDATE, DELETE metoda ta zwróci liczbę wierszy objętych modyfikacją). Uwaga metoda rowCount może nie działać w przypadku niektórych baz danych.

Metoda fetchAll($fetch_style) zwraca tablicę z wynikami. Domyślny argumentem $fetch_style tej metody jest FETCH_BOTH, co powoduje, że zwracana tablica zawiera dane w postaci asocjacyjnej (indeksy odpowiadają nazwom pól tabeli) oraz liczbowej (liczby odpowiadające kolejności pól tabeli z zapytania). PDO::FETCH_ASSOC – pozwala ograniczyć zwracaną tablicę jedynie do stylu asocjacyjnego. Więcej informacji na temat różnych sposobów zwracania wyników znajdziecie na tej stronie: http://php.net/manual/en/pdostatement.fetch.php

Myślę, że te informacje będą wystarczające na dobry początek. Gorąco zachęcam do stosowania PDO. Szczególnie w przypadku gdy tworzony lub rozwijany projekt ma się cechować uniwersalnością i elastycznością w obsłudze różnego rodzaju baz danych.