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

[thek]

@adrix88: Odniosę się tylko do samej pętli, o której wspomniałem. Zauważ, że chcąc - nie chcąc i ta to robisz (IMG:style_emoticons/default/smile.gif) Różnica jest tylko w zapisie.
Albo puszczasz w pętli takiej jak ja przedstawiłem mniej więcej, albo robisz tyle instrukcji bindowania ile masz parametrów dla jawnego odwołania w PDO. A teraz niby walnięcie tych kilkudziesięciu parametrów w mysql_real_escape_string dla czystego odwołania funkcjami mysql_* miałoby utworzyć krótsze zapytanie?

Ja, nieważne czy używam pdo czy mysql_* to i tak trzymam wszystkie dane mające iść do bazy w tablicy i tylko potem lecę w pętli z escape'owaniem lub bindowaniem. Oszczędzam wieeeeele linijek kodu lub pisania kosmicznie długiego zapytania z jawnym wywołaniem funkcji mysql_real_escape_string dla każdej wartości. Narzut czasowy tak naprawdę jest nieznaczny, za to czytelność i prostota kodu są nieporównywalne.

Inna sprawa, że dla mnie zapytanie puszczone w pętli sugeruje, iż spaprałem strukturę tabel (IMG:style_emoticons/default/wink.gif) W najcięższych przeze mnie stworzonych projektach do wygenerowania całej strony zazwyczaj nie przekraczam liczby 10 zapytań (IMG:style_emoticons/default/wink.gif) Czasem są one długie i mają wiele joinów, ale elastyczność tabel sprawia, że dodawanie nowych funkcjonalności to po prostu pikuś. A tak patrząc na strukturę tabeli jaką dałeś, to domyślam się, że to tabela o nazwie "Product" i z marszu mogę powiedzieć, że bez problemu bym pewnie ją na dwie lub trzy rozbił. Czemu? Bo na bank i tak za każdym razem nie wykorzystujesz wszystkich danych. Pewne zapytania najczęściej używane pobierają tylko określone kolumny a reszta i tak leży odłogiem czekając na bardziej specjalizowane żądania. Myślisz, że wydajniejsze dla bazy jest przelatywanie prze jedną tabelę z 60 kolumnami po to by wybrać tylko 10 kolumn w 90% przypadków czy podzielić tę tabelę na dwie, z których jedna będzie dokładnie te 10 kolumn zawierać, zaś druga pozostałe + id? Jakoś nie wierzę, że uprawnienia konfiguracyjne związane z edycją są przy byle prostym wyświetlaniu konieczne do pobrania i sprawdzania (IMG:style_emoticons/default/smile.gif) Ogólnie jednak zgadzam się z Crozinem - wszystko zależy od tego JAK pracujesz z bazą, jakie zapytania doń idą. Najczęściej jednak taka ilość kolumn sugeruje, że coś nie tak jest i warto pomyśleć o optymalizacjach struktury.