Gotowa klasa do łączenia się z MYSQL przez PDO, MySQLi oraz MySQL Opcje

[adrix88]

Witam. Ostatnio zabrałem się za pisanie klasy do obsługi połączeń MySQL i poszukując inspiracji w sieci znalazłem dosyć ciekawą klasę do obsługi baz w której możemy wybierać typ połączenia PDO, MYSQLi lub MYSQL, tego w sumie potrzebowałem. Napiszcie co myślicie o tej klasie, jest waszym zdaniem dobrze napisana? Czy może znacie jakieś inne gotowe sprawdzone klasy?

LINK DO KLASY

Ten post edytował adrix88 23.06.2011, 23:36:37

[Fifi209]

Pisanie "nakładek" na mysql_ czy mysqli_ o pdo nie wspominając to kpina. (IMG:style_emoticons/default/wink.gif)

Samo PDO udostępnia całkiem niezłą funkcjonalność, w wielu przypadkach wystarczy, nie miałem jeszcze przyjemności (lub nieprzyjemności) używać ORM.

Powiedz do czego Ci ta klasa? W celach edukacyjnych? Chcesz mogę Ci dać 10 innych tematów, na których możesz poćwiczyć obiektówkę.

[zegarek84]

Powiedz do czego Ci ta klasa?

choćby do większej uniwersalności kodu??

możesz mi nie wierzyć w to co teraz napiszę - sam byłem zaskoczony - ale jak jedną rzecz pisałem znajomemu okazało się, że nie mogę się połączyć z bazą mysql przez PDO gdzie ono było skompilowane o.O - z kolei jak druga mniejszą rzecz pisałem to już skorzystałem ze sqlite które tam można było utworzyć właśnie tylko przez PDO... wszystko zależy jak PHP na danym serwerze jest skompilowane...

Ten post edytował zegarek84 23.06.2011, 22:45:39

[adrix88]

Generalnie chodzi mi właśnie o uniwersalność, żeby w każdym projekcie używać tej samej klasy do mysqla, a dodatkowym argumentem jest chęć przetestowania wydajności poszczególnych połączeń mysql na "żywym" organizmie, w różnych projektach. Wiele osób twierdzi że PDO jest wolniejsze od mysqli, natomiast jeszcze inni twierdzą że PDO jest szybkie w dużych aplikacjach, jak z tym jest tak naprawdę to nie wiem, ale chciałbym mieć możliwość przełączenia się pomiędzy tymi interfejsami.

[zegarek84]

do pojedynczego zapytania może i PDO wolniej wypadnie ale pomijając kwestię transakcji to w PDO możesz bindować zapytania SQL co jest z jednej strony bezpieczniejsze, z drugiej strony przy większej liczbie zapytań szybsze - oczywiście przy większej liczbie uaktualnień w bazie lepiej włączyć transakcje...

poza tym PDO masz wkompilowane w samo PHP - gdybyś wszystko to samo chciał zrobić to samo w samym PHP to napewno było by to wolniejsze ;]

Ten post edytował zegarek84 23.06.2011, 23:01:55

[Fifi209]

choćby do większej uniwersalności kodu??

Wiesz jak to się mówi: jeżeli coś jest do wszystkiego to jest do niczego

z drugiej strony przy większej liczbie zapytań szybsze - oczywiście przy większej liczbie uaktualnień w bazie lepiej włączyć transakcje...

Co mają transakcje do szybkości?

Generalnie chodzi mi właśnie o uniwersalność, żeby w każdym projekcie używać tej samej klasy do mysqla

Nic nie jest uniwersalne, nawet jeżeli napiszesz coś w miarę uniwersalnego, to i tak przy którymś projekcie będziesz musiał ją rozszerzać.

, a dodatkowym argumentem jest chęć przetestowania wydajności poszczególnych połączeń mysql na "żywym" organizmie, w różnych projektach.

Wydajność zależy nie od samego PHP, dobre zaprojektowanie bazy danych, założenie odpowiednich indeksów. Poza tym, przy dzisiejszej mocy obliczeniowej procesorów - różnica rzędu 0.0001 sek nie będzie zauważalna nawet przy dużej liczbie odwiedzin.

[adrix88]

Widzę że dosyć dobrze ogarniacie PDO, bo ja to przyznam szczerze że dotychczas łączyłem się wyłącznie przez mysql. Mam do ciebie takie pytanie, nie wiem czy przeglądałeś tą klasę co podałem w temacie, ale zakładam że tak. Z tego co widzę to dane które dodawane są w zapytaniach mysql i mysqli są potraktowane funkcją mysql_escape_string, natomiast w przypadku w klasie z PDO brak jest tego filtrowania, hmm, czyli w tej klasie jest jakieś inne zabezpieczenie przed sql injected, czy też może brak w niej jakichkolwiek zabezpieczeń? Bo osobiście nie widzę tam niczego co mogłoby zabezpieczać przed tym atakiem, ale nie znam się na funkcjach PDO, więc mogę się mylić.

Ten post edytował adrix88 23.06.2011, 23:10:04

[Spawnm]

Masz bindowanie oraz execute (IMG:style_emoticons/default/wink.gif)

[zegarek84]

Co mają transakcje do szybkości?

wgrywałeś/aktualizowałeś kiedyś co jakiś czas minimum po 3-5 tys. rekordów? - wiem - to bardziej od strony administracyjnej lub do jakichś tam narzędzi ale różnica nawet na lokalnym komputerze jest ;]

[Fifi209]

Transakcje

Tyle w temacie transakcji.

[zegarek84]

kiedy właśnie te minimum 3-5k rekordów minimum stanowi całość ;p [choć da się w sumie wgrać osobno a potem sprawdzić czy coś poszło nie tak - ale skoro to ma być razem to tylko wydłuży cały proces]

i pojedynczy insert bez włączenia transakcji też jest w obrębie ale własnej transakcji - gdy skożystasz z transakcji rozpoczęcie i zamkniecie jest wykonywane tylko raz ;p

Transakcja składa się zawsze z 3 etapów:

1. rozpoczęcia
2. wykonania
3. zamknięcia

tyle w temacie transakcji (IMG:style_emoticons/default/wink.gif)

Ten post edytował zegarek84 23.06.2011, 23:30:12

[adrix88]

Kurcze, porobiłem właśnie kilka zapytań PDO i muszę wam powiedzieć że te bindowanie jest strasznie niewygodne. Mam np. inserty po 60 pól i dla każdego z tych pól tworzyć bindy to jest przecież katorga, a to przecież tylko 1 zapytanie. Już wolę filtrowanie funkcją tak jak to robiłem w mysql, bo to co daje PDO to jakaś tragedia. Czy to filtrowanie od PDO jest naprawdę lepsze od poczciwego real_escape_string + stripslashes dla magic_quotes on?

Ten post edytował adrix88 23.06.2011, 23:43:18

[Fifi209]

Tak.
magic_quotes - oby zniknęło jak najprędzej, to zło, wystrzegaj się

Pisałem wcześniej o projektowaniu bazy danych, jesteś idealnym przykładem jak nie projektować bazy, 60 pól w tabeli? Chyba oszalałeś...

@zegarek
Przy 3-5k rekordów raczej skorzystałbym z poczciwego source lub chociaż load data niż bawił się w dodatkowych pośredników jak php.

Ten post edytował Fifi209 24.06.2011, 02:04:27

[adrix88]

Fifi209, a co w tym złego że jest 60 pól w tabeli? chyba nie będę joinował kilka tabel żeby zmniejszyć liczbę pól w jednej tabeli. Jeżeli specyfikacja skryptu wymaga przechowywania tylu danych w tabeli to nawet żebyś był najlepszym programistą to tego nie przeskoczysz... Widziałeś w ogóle strukturę tabel np. w vBulletin'ie? W tym skrypcie są tabele grubo przekraczające liczbę pól którą podałem. Im większy projekt tym więcej danych i żebyś nie wiem jak chciał to tego nie przeskoczysz...

[nospor]

Im większy projekt tym więcej danych i żebyś nie wiem jak chciał to tego nie przeskoczysz...

Wszystko zależy od projektu. Nie wiemy co tam u Ciebie było i czy te 60 pól było uzasadnione czy nie.

Mam np. inserty po 60 pól i dla każdego z tych pól tworzyć bindy to jest przecież katorga, a to przecież tylko 1 zapytanie.

Może coś źle zrozumiałeś, może coś źle robisz, ale ja tam w bindowaniu nie widzę żadnej katorgi.

Czy to filtrowanie od PDO jest naprawdę lepsze od poczciwego real_escape_string + stripslashes dla magic_quotes on?

Niby w czym bindowanie jest bardziej katorgą od używania real_escape_string + stripslashes? Chyba, naprawdę coś źle robiłeś (IMG:style_emoticons/default/wink.gif)
Co do magic_quotes to fifi już napisał co należy z tym zrobić.

[zegarek84]

@zegarek
Przy 3-5k rekordów raczej skorzystałbym z poczciwego source lub chociaż load data niż bawił się w dodatkowych pośredników jak php.

fajnie się pisze - inna sprawa, że te dane pochodzą z innego programu i trzeba te dane z xml'a wyciągnąć ;]

[Fifi209]

zegarek, wiesz dla chcącego nic trudnego, o czym my tu dyskutujemy? Napisać program w C++ czy C#, który zapisze te dane w postaci CSV i wtedy load data...
Nie ciągnijmy już tego tematu, sposobów tyle co programistów. (IMG:style_emoticons/default/wink.gif)

[adrix88]

Wszystko zależy od projektu. Nie wiemy co tam u Ciebie było i czy te 60 pól było uzasadnione czy nie.

No tak. Tylko że akurat w tym projekcie te 60 pól jest raczej uzasadnione, ponieważ są tam przechowana id, nazwa, parametry danej usługi, data startu, data wygaśnięcia, cena. Więc akurat w tym przypadku nie widzę możliwości ograniczenia tych pól, bo każde z nich jest kluczowe.

Może coś źle zrozumiałeś, może coś źle robisz, ale ja tam w bindowaniu nie widzę żadnej katorgi.

hm, robię to tak jak widać poniżej:

Dla zwykłego MySQL:

[PHP] pobierz, plaintext 
$query = mysql_query("SELECT * FROM `tabela` WHERE `var1` = '".sql($_GET['var1'])." AND `var2` = '".sql($_GET['var2'])."' AND `var3` = '".sql($_GET['var3'])."'' AND `var4` = '".sql($_GET['var4'])."' ");
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
while($dane = mysql_fetch_array($query)) {
echo $dane['id'];
echo $dane['nazwa'];
}
[PHP] pobierz, plaintext 

Dla PDO:

[PHP] pobierz, plaintext 
$query = $pdo->prepare('SELECT * FROM `tabela` WHERE 
`var1` = :var1 AND 
`var2` = :var2 AND 
`var3` = :var3 AND
`var4` = :var4 ');
$query->bindValue('var1', $_POST['var1'], PDO::PARAM_STR);
$query->bindValue('var2', $_POST['var1'], PDO::PARAM_STR);
$query->bindValue('var3', $_POST['var1'], PDO::PARAM_STR);
$query->bindValue('var4', $_POST['var1'], PDO::PARAM_STR);
 $query->execute();
$array = $query->fetchAll();
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
foreach($arraye as $dane){
echo $dane['id'];
echo $dane['nazwa'];
}
[PHP] pobierz, plaintext 

//////
Nie wiem czy robię wszystko poprawnie, ale na powyższych przykładach widać że tworzenie zapytań w mysql jest znacznie prostsze i szybsze oraz jest mniej kodu, a w PDO jednak trzeba się napisać ...

Niby w czym bindowanie jest bardziej katorgą od używania real_escape_string + stripslashes? Chyba, naprawdę coś źle robiłeś (IMG:style_emoticons/default/wink.gif)
Co do magic_quotes to fifi już napisał co należy z tym zrobić.

Robiłem to tak jak widać na przykładach powyżej, przecież nikt o zdrowych zmysłach nie używa samego real_escape_string na wartościach dodawanych w zapytaniu, do tego celu tworzy się funkcję czyszczącą która w przypadku gdy magic_quotes jest na on kasuje ukośniki przez stripslashes i następnie przemiela wartości przez real_escape_string. Wtedy tylko wywołuje się taką funkcję przy każdej zmiennej w zapytaniu np. sql($_GET['var']) i jest wszystko pięknie i przyjemnie. A jeżeli chodzi magic_quotes to wiem co z nim zrobić, chyba źle zrozumieliście mój post w którym o tym wspomniałem.

===============
Mam jeszcze do was takie pytanie, czy stosujecie jakieś nakładki na PDO, własne klasy obsługujące itd. czy korzystacie z tego standardowo bez żadnych nakładek? Bo z tego co czytałem kilka wypowiedzi z forum to nie ma sensu stosowanie własnych nakładek na PDO, chociaż osobiście nie do końca rozumiem dlaczego, co prawda nie znam jeszcze za dobrze tego typu połączenia z bazą, ale bo krótkiej zabawie, wydaje mi się że napisanie dodatkowej klasy obsługującej PDO ma sens i może przyśpieszyć pisanie kodu, ułatwić w przyszłości przejście na inny interfejs połączenia z bazą, a także daje możliwość dopisania funkcji liczących liczbę zapytań, ich czas, czy też zapisywanie wykonywanych zapytań itd. Chciałbym wiedzieć jaki jest wasz stosunek do tego. Korzystacie z własnych nakładek, czy to nie ma sensu i dlaczego?

Ten post edytował adrix88 24.06.2011, 16:00:54

[zegarek84]

Nie wiem czy robię wszystko poprawnie, ale na powyższych przykładach widać że tworzenie zapytań w mysql jest znacznie prostsze i szybsze oraz jest mniej kodu, a w PDO jednak trzeba się napisać ...

na upartego przygotowane zapytanie nie musisz wcale bindować ;p - poczytaj w manualu PDOStatement->execute
a przede wszystkim zwróć uwagę na przykład drugi i trzeci:
http://pl2.php.net/manual/en/pdostatement....php#example-955

EDIT
Widzę, że źle bindujesz!!! Binduje się nazwy z dwukropkiem (poprzedzone nim) czyli np. :var1 lub jeśli masz znaki zapytania to kolejno przy bindowaniu numerujesz od 1 zaś dając tablicę do execute od 0 (co zresztą samo się ponumeruje nie ustawiając kluczy w tablicy)

Ten post edytował zegarek84 24.06.2011, 16:11:08

[thek]

Znasz strukturę zapytania? Znasz. To w czym jest trudność zastosować:

[PHP] pobierz, plaintext 
foreach( $_POST AS  $key => $value) {
    $query->bindValue( $key, $value, PDO::PARAM_STR);
}
[PHP] pobierz, plaintext 

lub czegoś w tym stylu po drobnych przeróbkach?