Forum PHP.pl

Zazwyczaj gdy spotykam kody różnego pokroju w PHP to czesto warstwa logiczna od wyglądu jest oddzielona.
Pal licho jeśli obsługa np. mysql'a jest w jakiś przystępny sposób zrobiona i do tego ktoś wykorzystał np. pdo i "przygotowywanie zapytań".

Ale często spotykam się też z kodami gdzie zapytanie jest przygotowywane strukturalnie i dość często przy nieco bardziej złożonych mam problemy z ich rozszyfrowaniem (IMG:style_emoticons/default/blinksmiley.gif)

Powstaje więc pytanie czy: warto oddzielić tę warstwę (jeśli taka istnieje) bazy danych - czyli to gdzie te duperele są obsługiwane i wypisać zapytania tak by znajdowały się w oddzielnym pliku i stworzyć coś na wzór smarty?

Dla przykładu zapytanie

[SQL] pobierz, plaintext 
SELECT
  `nazwa`,
  `opis`,
  `zdjecie`
FROM
  `jakasTabela`
{IF $id}
WHERE
  `id` = {$id}
{else}
ORDER BY `id` DESC
LIMIT 0, 30
{/IF}
[SQL] pobierz, plaintext 

i np. taki kod w php który to przetworzy i wyciągnie zapytanie np. z xml:

[PHP] pobierz, plaintext 
 
$zapytanieOdczytaneZPlikuXML = ...;
 
$dbPattern = new ParserSQL;
$dbPattern->assign('id', 123);
 
$dbPattern->parse( $zapytanieOdczytaneZPlikuXML );
 
// Wypisujemy te zapytanie na ekran
var_dump( $dbPattern->model );
 
//..dalsza część skryptu...
 
[PHP] pobierz, plaintext 

Pytanie czy warto czy nie warto?
Co ważne czy tak przygotowane zapytania były by wygodne w "obróbce", zmianach?
Czy przeciętny PHPMaster wiedział by o co w tym chodzi?

Przy zapytaniach typu select * from costam where .... order by costam limit 1,10 nie warto przy zlozonych zapytaniach ktore moze miec nawet kilkanascie relacji warto wiem bo ostatnio kolega mi wlasnie pokazal takie rozwiazanie w jego fw spoczatku nie wiedzialem o co biega ale jest to wydajniejsze.

no właśnie chodzi o złożone zapytania.

Swojego czasu napisałem klase którą przez pewien czas udoskonalałem i dorobiłem pętle, warunki i pare innych drobiazgów.

...ale jakoś nie miałem do czego tego wykorzystać. Planuję ruszyć z kopyta z pewnym projektem i muszę rozwiązać wszystko tak by to było dostępne dla innych programerów...

jeśli by ktoś chciał klase z samplem to pisac na pw

O czym Ty mówisz? Twierdzisz, że budując zapytanie w taki sposób (jakimś builderem) wykona się ono szybciej? Przecież i tak finalnie zrobiony z tego zostanie string, który będzie przekazany jako argument do funkcji *_query(). Takie rozwiązanie na pewno nie będzie wydajniejsze; będzie wręcz mniej wydajne.

Ja napisałem sobie klasę, która dynamicznie tworzy mi zapytania (natchnęła mnie do tego klasa z Kohany), ale nie ze względu na wydajność, a dla wygody użytkowania:

[PHP] pobierz, plaintext 
$query = new Database_Query_Builder();
 
$query
	->select('*')
	->from('tabela')
	->join('inna', array('inna.tabela_id' => 'tabela.id'))
	->order_by('jakies_pole', 'ASC')
;
 
if (jakis_warunek) {
	$query->where('inne_pole', 10);
}
 
if (inny_warunek) {
	$query->where('kolejne_pole', array(1, 2, 3), 'IN');
}
[PHP] pobierz, plaintext 

Dzięki dynamicznemu dodawaniu warunków/sortowań/złączeń itd. zdecydowanie wygodniej jest mi w ten sposób tworzyć zapytania.

PS: odszedłem nieco od tematu więc do niego powrócę. Wspomniane przez autora "templatowanie" zapytań to nic innego jako model (w MVC). W modelu zawierasz wszystkie zapytania i masz je w jednym miejscu, a nie porozrzucane po całym systemie.

Ten post edytował phpion 19.11.2009, 12:44:50

Dokładnie tak - znam model MVC i wiem na czym polega. Z tym że jestem za extreme programing - a od tego ostatnio się już odeszło i z tego co widzę to wraca się ponownie bo nikt nie ma czasu na tworzenie pięknego kodu (IMG:style_emoticons/default/smile.gif)

...stąd te pytanie, skoro nikt nie ma czasu na ładny kod to trzeba przygotować "zaplecze" tak by całość była odpowiednio poskładana.

oj błogosławieni ci którzy w pracy robią to co chcą (IMG:style_emoticons/default/haha.gif)

Query buildera to ja tez uzywam nie chodzi mi o niego, zreszta napewno szybciej zadziala zwykle mysql_query() niz wszystkie te akcje co musi zrobic query builder na stringach i tablicach.

Chodzi o zwykle template'ki dla zapytan sql.

Takie CV dla sql w V trzymamy template zapytanie SQL a za pomoca C wypelniamy tylko potrzebne nam rzeczy jesli czesto mamy takie same zapytanie i zmienie sie tylko warunek where lub nazwa tabeli i kolumn to tak tez sie robi.

no tak, ale wzorem smarty przetworzone zapytanie może być zapisane jako plik PHP i taki skompilowany plik nie musi być już przetwarzany ponownie do czasu aż skrypt zauważy że we wzorcowym pliku z szablonami zapytań dokonano zmian. Wtedy zaś to przetworzy i zapisze te zapytanie do PHP...

Szybkość tu akurat jest tu istotnym elementem, ale sensownie przemyślane rozwiązanie może być dostępne i na tyle szybkie że nie zabije serwera...

Już na wejściu robicie ten sam błąd, co twórcy 98,9% systemów szablonów dla warstwy widoku: udostępniacie ograniczony pozdbiór języka PHP, który będzie do wyrzucenia po napotkaniu pierwszego trudniejszego problemu. Ani to nie będzie przez to bardziej czytelne, ani łatwiejsze w użyciu. Mnożone są niepotrzebnie byty: zapytań SQL w serwisie może być bardzo dużo, nie tworzą one aż tak samodzielnej całości. Z punktu widzenia czytelności kodu lepszym rozwiązaniem jest, aby były one generowane mniej więcej w miejscu wywołania, a nie trzymane gdzieś w zupełnie innym katalogu. Nie wiem, najprawdopodobniej da się stworzyć coś fajnego dla zapytań opartego na szablonach mniej więcej na wzór OPT, by to faktycznie w czymś pomagało, ale w takim kształcie szkoda zachodu. Już obiektowy query builder jest bardziej przydatny, bo przynajmniej operuje się na zapytaniu jak na obiekcie i można go przekazać do jakiegoś innego elementu, by ten go czymś jeszcze obudował... proponuję znaleźć choć jedną funkcjonalną różnicę między poniższymi kodami:

[PHP] pobierz, plaintext 
class Model
{
   public function pobierzListe($dane)
   {
      $query = 'SELECT * FROM costam';
      if(warunek1)
      {
         $query .= ' INNER JOIN cos_innego ON costam ';
      }
 
      if(warunek2)
      {
         $query .= 'WHERE a = b';
      }
      return $this->execAndReturn($query);
   } // end pobierzListe();
} // end Model;
[PHP] pobierz, plaintext 

Od:


+ klasa opakowująca.

Przykład nieco trudniejszy: warunków może być "n", w tym także 0 - wtedy "WHERE" nie powinno być generowane. Taka uproszczona składnia już w tym miejscu albo leży, albo dostajemy gigantycznego ifa z konkatenacją np. 50 warunków, które później są szczegółowo powtarzane.

Ten post edytował Zyx 19.11.2009, 16:38:38