Na forum php.pl pojawił się post z pytaniem czy zastosowanie prepared statements wpływa na wydajność zapytań.

Troszeczkę teorii:

Jak to wygląda od strony ORACLE:

Zanim dane zostaną zwrócone z bazy danych, po odebraniu odpowiedniego kodu baza danych Oracle musi wykonać określone czynności:

• tworzenie kursora
• proces parsowania zapytania jeśli nie istnieje w obszarze wspólnym. Na proces ten również wchodzi kilka etapów:
  • analiza zapytania - sprawdzenie czy zapytanie składniowo jest poprawne
  • sprawdzenie odwołań do obiektów
  • sprawdzenie uprawnień
  • modyfikacja zapytania, w celu uzyskania zapytania równoważnemu danemu, ale wykonywanemu efektywniej
  • przygotowanie planów wykonania na podstawie statystyk, wskazówek
  • wybranie najlepszego planu wykonania (najmniejszy koszt wykonania)
  • zapisanie do obszaru wspólnego

  Wykorzystanie wcześniejszego zapytania jest możliwe tylko wtedy, kiedy:

  • tekst zapytania jest taki sam (wchodzą w to również komentarze i białe znaki),
  • polecenie musi odwoływać sie do tych samych obiektów w bazie danych,
  • zmienne wiązane muszą się tak samo nazywać i być tego samego typu.

• przygotowanie zapytania
• podwiązanie zmiennych
• wykonanie zapytania
• zwrócenie rekordów do użytkownika

Jeśli do bazy danych jest wysyłane takie samo zapytanie proces parowania nie jest wykonywany, przez co wydajność wzrasta bo pewna czść operacji jest pomijana.

Czy zawsze stosować takie rozwiązanie?

Są przypadki zapytań dla których najlepszy plan pierwszego wykonania dla pewnych parametrów jest nieoptymalny i zaleca się nie stosowanie zmiennych wiązanych.

MySQL:

Jeśli chodzi o bazę danych MySQL mechanizmy nie są aż tak bardzo zaawansowane ale pewne rzeczy są zaimplementowane.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Jak każdy programista przychodzi czas na to by ułatwić sobie pracę, piszemy dziesiątki albo i setki małych lub większych narzędzi. W 90% przypadków używamy ‘echo’ lub ‘print’ zamiast systemu szablonów i jest to chyba dość oczywiste. Najnormalniej w świecie jest to zbędne i szkoda na to czasu. Ale czemu rezygnować z jakiegoś ładnego formatu, zaznaczenia ważnych rzeczy lub błędów które pojawiły się podczas pracy. W HTML’u nie jest to trudne, użycie stylu nadanie mu koloru czcionki i po sprawie. Sprawa może wyglądać trochę gorzej jeśli (np. tak jak ja) robicie małe skrypty odpalane pod konsolą Linuksa. Tak zazwyczaj tekst jest zawsze biały, a tło czarne. Kolorowanie tekstu pod konsolą jest stosunkowo proste. Trzeba jedynie pamiętać o tym, aby po wyświetleniu treści przywrócić kolor do swojej pierwotnej postaci. Format kolorowania tekstu jest dość prosty, składa się ze znaku specjalnego ESCAPE, oraz definicji kolorów. Aby otrzymać znać ESCAPE użyjemy jego zapisu ósemkowego (Wartość \033, zapisana jako ‘\033‘), zupełnie tak samo jak w konsoli Linuksa oraz funkcji echo. Nastepnie po znaku ‘[‘ może występować do trzech wartości określających fomat tekstu, wszystkie oddzielane od siebie znakiem średnika ‘;’. Cały kod zakańczamy literą ‘m’. W całości kod tworzony jest na takiej zasadzie.

\033[kod_formatujący;kod_koloru;kod_tłam

przykład: \033[1;31mCzerwony gruby napis\033[0m otrzymamy taką treść Czerwony gruby napis Oczywiście nie musimy na końcu dawać kodu ‘\033[0m’ ale cała konsola będzie wyświetlać jedynie czerwoną pogrubioną czcionkę do czasu aż zostanie ona zamknięta lub otrzyma kod resetujący ustawienia. Poniżej podaje listę kodów które można wykorzystać do formatowania konsoli. Kody formatujące

• 0 – resetuje wszystkie ustawienia
• 1 – pogrubiona
• 2 – przyciemniona czcionka
• 4 – podkreślona
• 5 – mrugająca
• 7 – zamienia miejscami kolor czcionki i tła

Kody kolorów czcionki

• 30 – czarny
• 31 – czerwony
• 32 – zielony
• 33 – brązowy
• 34 – niebieski
• 35 – magenta
• 36 – turkusowy
• 37 – biały

Kody kolorów tła

• 40 – czarny
• 41 – czerwony
• 42 – zielony
• 43 – brązowy
• 44 – niebieski
• 45 – magenta
• 46 – turkusowy
• 47 – biały

Poniżej podaje przykład jak zastosować to praktycznie w kodzie PHP. Szczerze mówiąc jest to jedynie wycinek który wykorzystuje w swoich klasach, można to oczywiście zamienić na normalną funkcję. Używana przeze mnie metoda używana jest aby wyświetlać pokolorowaną treść w konsoli oraz w przeglądarce. Równie dobrze można by zdefiniować wszystkie kolory tła i format czcionek, ale podejrzewam, że każdy może to zmodyfikować w swoim zakresie.

Przykładowa klasa Display której sam używam.

bibliografia: http://www.newlinuxuser.com/linux-console-codes/ http://www.linux.gr/cgi-bin/man2html?console_codes+4 oraz wielkie Google

DataGrid for Zend Framework

Wczoraj wieczorem na forum zend-framework.pl pojawił się link do ciekawego projektu realizującego tak oczekiwany przez wielu scaffolding.  Projekt nazywa się DataGrid for Zend Framework i obudził moje nadzieje na szybkie implementacje CRUD w rozwijanych przeze  mnie projektach. Niestety, nie jest jeszcze aż tak różowo

Po wstępnych testach mogę już napisać parę słów co o tym sądzę, i niestety optymizm miesza się z garścią zawodów. O ile sam “grid” działa bezproblemowo, można szybko i prosto wstawiać sortowalne i paginowalne (dziwne słowo) tabele do projektów, to sposób realizacji jest już mniej przyjemny.

Niestety, cały system działa w oderwaniu od zendowskich modeli. Inicjalizacja grida wygląda mniej więcej tak:

$grid = new $grid (  $db, 'Grid Example', APPLICATION_PATH . 'public_html/temp', array ('download', 'save' ) );
$grid->from ( 'table' )->order ( 'id ASC' );

Jak widać wewnątrz kontrolera musimy nie tylko mieć adapter bazy, ale także znać dokładną nazwę tabeli.  W moim przypadku kiedy samych baz w projekcie mam 6, a tabel nawet nie liczyłem, jest to kłopotliwe.

Kolejny problem wynikający z niekorzystania z modeli, jest niemożliwość zachowania logiki biznesowej która w takich modelach może się znajdować.  Bardzo często w modelach wykorzystuję $_rowClass i możliwości oferowane przez takie metody jak Zend_Db_Table_Row::_insert() Zend_Db_Table_Row::_postUpdate().  Pozwala mi to automatycznie filtrować dane, czyścić odpowiedni cache przy modyfikacjiach, tworzyć/modyfikować powiązane wpisy itp. Oderwanie grida od modelu uniemożliwia natomiast takie rozwiązania i zmusza do dodatkowego kodu.

Resumując, na obecnym etapie ten komponent może się sprawdzić jako narzędzie do szybkiego przeglądu zawartości tabel (zwłaszcza jeśli w modelu zaimplementujemy sobie metodę w rodzaju getGrid), ale jeśli chodzi o funkcjonalność CRUD to oderwanie ich od modeli w moich oczach dyskfalifikuje to rozwiązanie. Szkoda.

Related posts

• Łączenie wielu plików PDF w jeden (2)
• Zend_Captcha::factory() (2)
• Zend_Auth i modyfikowany rekord usera bazujący na Zend_Db_Table_Row (0)
• TCPDF i ZF (0)
• Firebug, FirePHP – nowa jakość w debugowaniu i monitorowaniu aplikacji (0)

Registry to wzorzec projektowy, który ma za zadanie przechowywać i udostępniać dane w obrębie aplikacji. Implementacja wzorca zastępuje globalny zasięg wartości zarejestrowanych w przestrzeni klasy. Różnicą globalnego zasięgu zmiennych oraz wartości ujętych w Registry jest to, że można je ściśle kontrolować (dostęp w aplikacji itd.). W tej publikacji przedstawię jedną z najprostszego wykorzystania wzorca Registry.

Głównym założeniem Registry jest globalny zasięg (pomijając już zabezpieczenia dostępowe, którymi się nie zajmujemy). Język PHP od wersji 5 obsługuje statyczne static wywołania metod klas, czyniąc tym samym ich globalny zasięg wraz z połączeniem ze słowem kluczowym public. Dla wygody - nie trzeba tworzyć instancji klasy, więc wywołanie jest bardzo proste i nie zajmuje dużo miejsca w naszym kodzie.

Podstawowymi funkcjonalnościami Registry będzie:

• dodawanie i usuwanie,
• pobieranie

…zmiennych z rejestru. Pojęcie zmienna jest bardzo względne. Przechowywać w rejestrze możemy praktycznie wszystkie typy zmiennych dostępnych w PHP, włączając w to typ resource (zasoby). Registry to nic innego, jak przechowywanie zmiennych w przestrzeni jednej klasy, więc nie mamy wobec tego żadnych ograniczeń.

• Przykładowy kod najprostszej implementacji wzorca Registry.
• Użycie powyższej klasy RegistrySimple.

Zajmiemy się teraz bardziej rozbudowanym przykładem wzorca. Wykonamy następujące operacje:

1. Nowa klasa RegistryAdvenced będzie dziedziczyła z RegistrySimple na potrzeby metody Registry().
2. Zaimplementujemy interfejsy:
   • Iterator
   • ArrayAccess (na potrzeby poruszania się po instancji jak po tablicy)
   • Countable (aby łatwo otrzymać liczbę przechowywanych danych)
   • Serializable (żeby można było zaserializować i odserializować instancję obiektu)
3. Dodamy prywatny konstruktor, skorzystamy ze wzorca Singleton.

Gotowy kod klasy RegistryAdvenced.

Interpretacja i rozwijanie swojego wzorca Registry jest szeroka, można na przykład zastosowac przestrzenie rejestrów, tj. tworzyć wiele rejestrów na podstawie ich instancji. Ile programistów, tyle pomysłów, ale zasada działania nie zmienia się. Zainteresowanych zapraszam do manuala, jak problem został rozwiązany w Zend_Registry.

Zend_Captcha_Image

Wczoraj przy okazji drobnych modyfikacji w jednym z starszych projektów zaszła potrzeba użycia mechanizmu Captcha. Oczywiście pierwsze spojrzenie padło na komponent Zend_Captcha. Po drobnych walkach związanych z błędami w dokumentacji (konkretnie przykład użycia isValid()), udało nam się doprowadzić ją do działania, i jak na razie się sprawdza. Przy okazji jednak zauwżyłem brak jednej, IHO bardzo przydatnej funkcjonalności jaką jest Factory. A skoro czegoś nie ma, to trzeba to sobie napisać

Zanim przejdę do klasy Factory, dla potomności i innych drobna uwaga na temat użycia isValid(). Dokumentacja ZF zawiera następujący przykład:

if ($captcha->isValid($_POST['foo'], $_POST)) {
    // Validated!
}

Natomiast z praktyki i analizy kodu wyszło nam że prawidłowa kontrukcja to:

			if ($captcha->isValid(
				array(
					'input' => $this->getRequest()->getParam('foo'),
					'id' => $this->getRequest()->getParam('id')
				) )) {
			    // Validated!
			}

To tyle dla potomności, teraz wracamy do sprawy Factory.

Dlaczego klasa faktorująca jest tak istotna? Przyjrzyjcie się jak działa Zend_Cache czy Zend_Db. W onfigu trzymamy sobie parametry konfiguracyjne, a w samym kodzie wywołujemy przykładowo:

$cache = Zend_Cache::factory ( $config->cache->frontend, $config->cache->backend, $config->cache->frontendOptions->toArray(), $config->cache->backendOptions->toArray());

Chcąc zmienić metodę cachowania czy dowolny parametr, robimy to w jednym pliku bez potrzeby wgłębiania się w kod i wyszukiwania wszystkich wystąpień. Natomiast w przypadku Zend_Captcha, każdorazowo w kodzie musimy decydować jakiego adaptera używamy oraz przekazywać parametry. Używając Zend_Captcha w kilku miejscach, i potrzebując nagle zmienić adapter np. z Zend_Captcha_Figlet na Zend_Captcha_Image, musimy wyszukać wszystkie wystąpienia, i ręcznie je zmienić.

Dlatego napisałem sobie Mao_Captcha::factory()

Przykłady użycia:

Standardowy Zend_Captcha_Image

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Zapewne wielu z nas często potrzebuje umieścić 2 elementy obok siebie używając Zend_Form. Dotychczas wydawało mi się że jedynym sposobem na to jest tworzenie własnych widoków formy. Jednak MAZI na forum Zend Framework polska społeczność znalazł sposób aby uzyskać ten sam efekt za pomocą dekoratorów bez potrzeby używania własnych widoków formy.

	    $submit->setDecorators(
	    	array(
	    		'ViewHelper',
	        	array(
	        		array(
	        			'data' => 'HtmlTag'
	        		),
	        		array(
	        			'tag' => 'td',
	        			'class' => 'element',
	        			'placement' => 'prepend',
	        			'openOnly' => 'true'
	        		)
	        	),
	        	array(
	        		array(
	        			'label' => 'HtmlTag'
	        		),
	        		array(
	        			'tag' => 'td',
	        			'placement' => 'prepend'
	        		)
	        	),
	        )
	    ); 

	    $cancel->setDecorators(
	    	array(
	        	'ViewHelper',
	        	array(
	        		array(
	        			'data' => 'HtmlTag'
	        		),
	        		array(
	        			'tag' => 'td',
	        			'class' => 'element',
	        			'placement' => 'append',
	        			'closeOnly' => 'true'
	        		)
	        	),
	        )
		);

Related posts

• Zend_Form i DHTML Calendar (0)
• Łączenie wielu plików PDF w jeden (0)
• Zend_Auth i modyfikowany rekord usera bazujący na Zend_Db_Table_Row (0)
• TCPDF i ZF (0)
• Firebug, FirePHP – nowa jakość w debugowaniu i monitorowaniu aplikacji (0)

Język SQL jest bardzo potężnym narzędziem do manipulacji bazami danych, lecz w każdym większym projekcie uciążliwe jest ręczne tworzenie setek zapytań, które w dodatku często nie wykraczają poza najprostsze możliwości. Najbardziej problematyczna część to przekształcanie danych na wewnętrzne struktury skryptu i vice versa. Tu z pomocą przychodzą systemy ORM (Object-Relation Mapper), zaś w tym wpisie chciałbym przedstawić jeden z nich - Doctrine.