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

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.

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

...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ą

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.