Witam,
Przymierzam się do stworzenia kolejnej strony - mini portalu. Oczywiście całość ma być oparta o bazę MySQL. W związku z tym moje pytanie. Jaka jest sensowna, rozwijana klasa do obsługi bazy danych MySQL? Czego warto użyć?
Pełna wersja: Poszukuje klasy do obsługi bazy danych
Cytat
Puszkuje klasy do obsługi bazy danych
W sensie, że "konserwuję"?
ja wykorzystuje własną implementacje mysqli wrzuconej we wzorzec singleton + pare dodatków do cache i tworzenia zapytań...
Nie wymyślaj koła na nowo, jest PDO
a PDO ma cache ? P
ma
Cytat(darko @ 17.09.2011, 15:24:13 ) 
ma
To chyba mnie coś omija... Gdzie PDO ma cache? Jakaś nowa wersja?
Zapytania preinterpretowane są cacheowane po stronie serwera:
[za:] http://php.net/manual/en/pdo.prepare.php
Oczywiście nie jest to cacheowanie poza warstwą serwera, ale w ramach tejże, jednak należy pamiętać, że mechanizm ten funkcjonuje dopiero od wersji MySQL 5.1.17
Cytat
Calling PDO::prepare() and PDOStatement::execute() for statements that will be issued multiple times with different parameter values optimizes the performance of your application by allowing the driver to negotiate client and/or server side caching of the query plan and meta information, and helps to prevent SQL injection attacks by eliminating the need to manually quote the parameters.
[za:] http://php.net/manual/en/pdo.prepare.php
Oczywiście nie jest to cacheowanie poza warstwą serwera, ale w ramach tejże, jednak należy pamiętać, że mechanizm ten funkcjonuje dopiero od wersji MySQL 5.1.17
Zacznijmy może od tego, że cache'owane może być tutaj 15 rzeczy na 20 sposobów każde, więc darujcie sobie tą dyskusję albo określcie dokładnie o cache czego chodzi.
Jeżeli chodzi o samo połączenie to PDO - raczej nic innego nie jest warte rozważania. Jeżeli zaś chodzi o jakieś bardziej przyjazne i rozbudowane API dla zapytań to wartym rozpatrzenia wydaje się być Doctrine DBAL.
Jeżeli chodzi o samo połączenie to PDO - raczej nic innego nie jest warte rozważania. Jeżeli zaś chodzi o jakieś bardziej przyjazne i rozbudowane API dla zapytań to wartym rozpatrzenia wydaje się być Doctrine DBAL.
1. Prepared statments z PDO to nie cache
2. Czasem lepiej napisać coś lekkiego i nie trzeba do prostego portalu używać takiego kombajnu.
Trzeba czytać ze zrozumieniem. Tutaj jest napisane, że do wersji 5.1.17 perpared statements z SELECT może powodować bardzo duży spadek wydajności. Tutaj nie ma nic o jej poprawie przy użyciu PS.
Co więcej cache dla "zwykłych" kwerend jest używane ZAWSZE (także poniżej 5.1.17). Nawet jeśli masz SQL > 5.1.17 i używasz PS to marginalnie szybsze może to być jedynie wtedy kiedy raz przygotujesz kwerendę którą potem wykonasz wiele razy. Z naciskiem na _może_, bo to nic pewnego. Jeśli przygotujesz kwerendę którą zaraz później raz wykonujesz PS jest WOLNIEJSZE, niż gdybyś tę samą kwerendę po prostu wysłał do serwera.
Moim zdaniem gra nie warta świeczki. ORM-y oczywiście są warte zainteresowania, jeśli akurat lubisz tłumaczyć świetny model SQL na model obiektowy który się do reprezentacji danych z tabel kompletnie nie nadaje i odpowiada ci prędkość żółwia. Moim zdaniem - przejściowa moda, żadnej bardziej skomplikowanej kwerendy w ORM-ie nie zrobisz i będziesz i tak musiał w końcu poznać SQL. Że o optymalizacji nie wspomnę.
2. Czasem lepiej napisać coś lekkiego i nie trzeba do prostego portalu używać takiego kombajnu.
Cytat
Using prepared SELECT statements on a MySQL database prior to MySQL 5.1.17 can lead to SERIOUS performance degradation.
Trzeba czytać ze zrozumieniem. Tutaj jest napisane, że do wersji 5.1.17 perpared statements z SELECT może powodować bardzo duży spadek wydajności. Tutaj nie ma nic o jej poprawie przy użyciu PS.
Co więcej cache dla "zwykłych" kwerend jest używane ZAWSZE (także poniżej 5.1.17). Nawet jeśli masz SQL > 5.1.17 i używasz PS to marginalnie szybsze może to być jedynie wtedy kiedy raz przygotujesz kwerendę którą potem wykonasz wiele razy. Z naciskiem na _może_, bo to nic pewnego. Jeśli przygotujesz kwerendę którą zaraz później raz wykonujesz PS jest WOLNIEJSZE, niż gdybyś tę samą kwerendę po prostu wysłał do serwera.
Moim zdaniem gra nie warta świeczki. ORM-y oczywiście są warte zainteresowania, jeśli akurat lubisz tłumaczyć świetny model SQL na model obiektowy który się do reprezentacji danych z tabel kompletnie nie nadaje i odpowiada ci prędkość żółwia. Moim zdaniem - przejściowa moda, żadnej bardziej skomplikowanej kwerendy w ORM-ie nie zrobisz i będziesz i tak musiał w końcu poznać SQL. Że o optymalizacji nie wspomnę.
Ja polecam EZ SQL - używam z powodzeniem od dawna:
http://justinvincent.com/ezsql
http://justinvincent.com/ezsql
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.