Witam,

Czy jest sens pisać klasę, która będzie tworzyć zapytania pod SQL? Nie chcę się później zatłoczyć tym w skrypcie więc pytam was o radę.

Pozdrawiam

Oczywiście, że jest... przy odrobinie pracy, można zdziałać cuda.

Spójrz na Zend_Db_Select.

Moje zdanie:
Nie ma sensu - po co?
Co Ci to da?

Napisałem sobie coś takiego

[PHP] pobierz, plaintext 
<?php
class MySQL {
	private $sql;
	private $executedQueries		= array();
	private $executedQueriesInt	 = 0;
 
	public function query($sql) {
		return mysql_query($sql);
 
		$this->executedQueries += $sql;
		$this->executedQueriesInt++;
	}
 
	public function insert($table, $data) {
		if(!empty($table) && count($data)) {
			$sql = 'INSERT INTO '.$table.' (';
 
			$keysInt = count($data);
 
			foreach($data as $key => $value) {
				$keys++;
 
				if($keys != $keysInt) {
					$sql .= "$key, ";
				} else {
					$sql .= $key;	
				}
			}
 
			$sql .= ') VALUES (';
 
			$keys = 0;
 
			foreach($data as $key => $value) {
				$keys++;
 
				if($keys != $keysInt) {
					$sql .= "$value, ";
				} else {
					$sql .= $value;	
				}
			}	
 
			$sql .= ')';
 
			$this->query($sql);
		}
	}
 
	public function update($table, $data, $where, $limit = NULL) {
		if(!empty($table) && count($data) && !empty($where)) {
			$sql = 'UPDATE '.$table.' SET ';
 
			$keysInt = count($data);
 
			foreach($data as $key => $value) {
				$keys++;
 
				if($keys != $keysInt) {
					$sql .= "$key = $value, ";
				} else {
					$sql .= "$key = $value";
				}
			}
 
			$sql .= ' WHERE '.$where;
			$sql .= (!empty($limit)) ? ' LIMIT '.$limit : '';
 
			$this->query($sql);
		}
	}
 
	public function delete($table, $where, $limit = NULL) {
		if(!empty($table) && !empty($where)) {
			$limit = (!empty($limit)) ? 'LIMIT '.$limit : '';
			$where = 'WHERE '.$where;
 
			$sql = "DELETE FROM $table $where $limit";
 
			$this->query($sql);
		}
	}
 
	public function getQueriesInt() {
		return $this->executedQueriesInt;
	}
 
	public function getQueries() {
		return $this->executedQueries;
	}
 
	public function getLastQuery() {
		return $this->sql;
	}
}
 
$db = new MySQL;
?>
[PHP] pobierz, plaintext 

klasa na razie bardzo uboga.

Przykład:

[PHP] pobierz, plaintext 
<?php
$array = array(
	'name'		 => 'Ktos',
	'password'	 => 'test',
	'from'		 => 'Poland',
	'age'		 => 'xx'
);
 
$db->insert('users', $array);
?>
[PHP] pobierz, plaintext 

nie wiem czy jest sens to dalej kodować czy pozostać przy bardziej standardowych metodach wykonywania zapytań.

załóżmy ze masz pobierac dane powiązane relacjami z roznych tabel i jeszcze do tego zagniezdzone zapytania i JOINy
oplaca sie pisac do tego taką "nakladke" ? Ja mysle ze nie

Myślałem, że chodziło Tobie o coś mapującego do SQL... np.

Query::select(Query::ALL)->from('Users')->where('name == 'LBO');

odpowiadając na pytanie w temacie, nie ma sensu pisać takiej klasy, ponieważ takcih rozwiązań już mamy dużo, szczególnie polecam osobny wątek o ORMach na tym forum

Ja mam pytanie jeszcze. Czy jest sens używać PDO ?

PDO to jest co innego
Jest sens, ale zalezy do czego

co do klasy tworzacej sql jaknajbardziej TAK, nawet jesli dziala ona tylko na proste inserty updaty to warto bo mozna ja napsiac tak ze mozna do niej poksojnie wyslac normalne zapytanie zlozone, przeciez fucja moze przymowac rozna liczbe parametrów, jak jest 1 czyli samo zapytanie leic od razu do bazy jak parametrów jest wiecej parsuje je i wysla zapynie do bazy

bo tak naprawde ulatwi to podstawowe operacje na bazie

bo jak czesto uzywamy mega zaawansowanych zapytan ....

PDO wprowadza pewną abstrakcję na źródło danych, więc raczej warto go używać. Chyba, że potrzebujesz nietypowych funkcji związanych z rozszerzeniem obsługującym bazę, tak jak zauważyli developerzy PHP:

jeszcze dorośniesz do odpowiedzi

To zdanie nic nie wnosi do dyskusji, jak komentować to z argumentami.
Ja dla takiego rozwiązania nie widzę na razie, w tym co robię, potrzeby używania, nie wnikając już w ogólny sens tworzenia tego.

Pisanie takiej klasy ma sens w jednym przypadku, gdy tworzysz jakąś aplikacje, którą później będziesz chciał przerobić na inną bazę danych.
Różnice w zapytaniach np między postgreSQL a MySQL są niewielkie ale jednak są ( chociażby fakt jak wstawia się limity i offsety do zapytań ).

Podczas korzystania z takiej klasy zmieniasz kod na potrzeby innej bazy w nieporównywalnie krótszym czasie niż szukanie każdego zapytania w kodzie we wszystkich skryptach.

Ale sam jestem przeciwny takiemu rozwiązaniu bo brakuje zapytań złożonych. Ja w tej chwili pracuje na takim obiekcie i mam do dyspozycji takie metody:
- wyciagnięcie wszystkich wyników z danej tabeli
- wyciągnięcie jednego wyniku z danej tabeli ( jednego wiersza )
- dodanie rekordu
- aktualizacja rekordu
- usuniecie rekordu
- wyciągniecie wszystkich wyników z wieloma warunkami
- wyciagnięcie danych z dwóch tabel ( tylko left join )

Do podstawowych skryptów wystarcza, ale miałem kilka przypadków gdy zamiast jednego zapytania wielokrotnie złożonego musiałem wykonać dwa zapytania z czego jedno w pętli.

Poza tym nie ma wpisanych wszystkich możliwości warunków ( jest równe, różne, in, not in, większe od ) a przecież SQL pozwala na dużo więcej.

Moja odpowiedź .. do prostych rzeczy można pisać taką klasę .. do bardziej zaawansowanych ( korzystających z dużych baz danych z bardzo rozbudowanymi relacjami ) mija się to z celem.

Dołączam się do tego co napisał Cienki1980.Napisałem klasę do obsługi bazy danych działającą na bibliotece PDO. Jeśli chodzi o proste proste zapytania wszytsko jest ok jednak przy tych trudniejszych (LEFT JOIN, formatowanie daty itp.) klasa już nie daje rady. Więc uważam tak jak przedmówca do prostych rzeczy taka klasa się świetnie sprawdza w przeciwnym przypadku już nie.

Pozdrawiam

racja, przepraszam
na początek wspomnę tylko że tak jak LBO myślałem że chodzi o ORM czy coś podobnego. Tworzenie klasy takiej jak załączona w którymś poście wyżej nie ma sensu, chyba że do nauki, ale to raczej marny pretekst. Takich rozwiązań jest pełno i szkoda że ludzie zamiast poświęcić chwilkę na naukę gotowca wymyślają własne imitacje nic nie wnoszące do tematu. jasne, ktoś może uważać że np. creole jest niewystarczające do jego potrzeb (w co wątpię) więc potrzebuje czegoś więcej. ale 99.9% wszystkich klas robi tylko query, limit i offset czy inne rzeczy nie wychodząc poza przyjęte standardy.
tak samo jest z orm - ludzie jadą po propelu bo nie pozwala na wygenerowanie niezwykle rozbudowanych zapytań łączących np. 4 tabele.i to jest powód do porzucenia wszystkich jego zalet i pisanie sql'a z łapy. tyle że większość z tych krytykujących takich zapytań nawet nie zobaczy we własnym projekcie, a poza tym jeśli nawet będą takie zapytania to najwyżej jedno na 20. to sorry, ale ja w takim wypadku wolę w 19/20 przypadków użyć propela w w tym jednym skorzystać z creole.

a poza tym w tej klasie załączonej jest błąd:

[PHP] pobierz, plaintext 
<?php
public function query($sql) {
		return mysql_query($sql);
 
		$this->executedQueries += $sql;
		$this->executedQueriesInt++;
	}
?>
[PHP] pobierz, plaintext 

jak zrobisz return mysql_query($sql); to reszta metody już się nei wykona, pomijając fakt że nie możesz zrobiść czegoś takigo jak $this->executedQueries += $sql; na tablicy

A wlasnie ze mozesz
http://www.php.net/manual/en/language.operators.array.php

a to ja mam chyba jakieś ubogie php

[PHP] pobierz, plaintext 
<?php
$arr = array();
$arr += '345';
?>
[PHP] pobierz, plaintext 

bo przecież parametr $sql jest stringiem...

Może:

[PHP] pobierz, plaintext 
<?php
$arr = array();
$arr[] = '345';
$arr[] = '678';
print_r($arr);
?>
[PHP] pobierz, plaintext 

?

A mi się wydaje, że dobrze jest pisać nawet takie proste klasy. Trudno mi sobie wyobrazić, że ktoś przesiada się z pisania sql "z palca" na propela. To jest po prostu naturalna ścieżka rozwoju
- piszesz wszystko sam
- wpadasz na przełomowy pomysł, że lepiej stworzyć jakąś klasę, która pozwoli ci na łatwiejsze wywoływanie zapytań, będzie się troszczyć o filtrowanie i escapowanie danych itp.
- potem odkrywasz, że jest coś co napisałeś, tylko pracowało nad tym wielu ludzi i działa znacznie lepiej, uwzględnia więcej możliwości itp.
- i wreszcie kończysz na orm'ach

Jestem w stanie założyć się, że każdy kto dziś używa propela wcześniej przeszedł coś takiego jak opisałem.

Co do istoty samej przytoczonej klasy - fakt jest mało poręczna i w prawie każdym projekcie wyjdzie, że czegoś jej brakuje, ale po pierwsze jest dobra na początek i w czasie projektu pewnie zostanie kilka razy poprawiona i przebudowana. A co najważniejsze umożliwia scentralizowane wywoływanie zapytań, a więc łatwe ich logowanie, obliczanie czasów ich wykonania itp.

Trudno mi się też zgodzić ze stwierdzeniem, że klasy "do sql" mają sens tylko, gdy korzystasz z różnych silników. Dla mnie to przede wszystkim wygoda tworzenia + to co opisałem wyżej. Powiem szczerze, że mam awersję do ręcznego pisania zapytań sql, łączenia stringów, rozbijania tablic do warunków in, dbanie o prawidłowe escapowanie daneych itp. Wolę jak większość automatycznych czynności wykona klasa za mnie.

Przeczytałem wasze wypowiedzi i doszedłem do wniosku, że budowanie klasy, która tworzy całe zapytania jest niepotrzebne, ponieważ to rozwiązanie jest mało elastyczne.
Napisałem sobie zatem, "na sucho" coś takiego:

[PHP] pobierz, plaintext 
<?php
 
class sqlArrayBuild {
	public $sqlArray = array();
 
	public function build($mode) {
		switch($mode) {
			case 'INSERT':
				$sql = '(';
				$sizeOfArray = count($this->sqlArray);
 
				foreach($this->sqlArray as $fieldName => $fieldValue) {
					$size++;
					$sql .= ($size < $sizeOfArray) ? $fieldName.', ' : $fieldName;
				}
 
				$sql .= ') VALUES (';
				$size = 0;
 
				foreach($this->sqlArray as $fieldName => $fieldValue) {
					$size++;
					$sql .= ($size < $sizeOfArray) ? $fieldValue.', ' : $fieldValue;
				}
 
				$sql .= ')';
 
				return $sql;
			break;
 
			case 'UPDATE':
				$sizeOfArray = count($this->sqlArray);
 
				foreach($this->sqlArray as $fieldName => $fieldValue) {
					$size++;
					$sql .= ($size < $sizeOfArray) ? $fieldName.' = '.$fieldValue.', ' : $fieldName.' = '.$fieldValue;
				}
 
				return $sql;
			break;
		}
	}
 
	public function clearArray() {
		$this->sqlArray = '';
	}
}	
 
?>
[PHP] pobierz, plaintext 

Przykład:

[PHP] pobierz, plaintext 
<?php
$sqlArrayBuild = new sqlArrayBuild;
 
$sqlArrayBuild->sqlArray = array(
		'id'	 => 2,
	'test'	 => 'test',
	'test2' => 'test'
);
 
$sql = 'INSERT INTO users '.$sqlArrayBuild->build('INSERT');
 
$sql = 'UPDATE users SET '.$sqlArrayBuild->build('UPDATE').' WHERE id = '.$sqlArrayBuild->sqlArray['id'].' LIMIT 1';
$sqlArrayBuild->clearArray(); 
?>
[PHP] pobierz, plaintext 

klasa nie tworzy całych zapytań, tylko ich część. Jest to ułatwienie przy dużej ilość używanych w zapytaniu kolumn. To już coś lepszego?

Ja też byłem kiedyś (no, nie tak dawno) przeciwnikiem ORM-ów, ale jak dobrałem się do dokumentacji Propela to już zrozumiałem jak bardzo się myliłem.

Tobie też radzę zaznajomić się z jakimś ORM-em. Polecam Propela.

a to ja odwrotnie - jak sie dobralem do Propela to do tej pory mam wstret do ORMów

Eee...

Zobacz:

[PHP] pobierz, plaintext 
<?php
$criteria = new Criteria();
$criteria->add(SettingsPeer::PROPERTY, 'title');
 
$title = SettingsPeer::doSelectOne($criteria);
echo $title->getValue();
?>
[PHP] pobierz, plaintext 

I wszystko jest przejrzyste, nawet dla osoby nie znającej SQL-a

To samo, tyle że w SQL:

[SQL] pobierz, plaintext 
SELECT value FROM settings WHERE property='title';
[SQL] pobierz, plaintext 

I do czego mieć wstręt?

Hmm, ja bym powiedzial ze samo SQL jest tu akurat 100 razy bardziej przejrzyste.

A jak uzywasz propela to i tak musisz znac SQl...

pewnie do tego że jest wolny, a przecież ten jeden użytkownik na godzinę musi mieć wygodę

pawel_k: Świetny dowcip, a co powiesz na to? :
Temat: Propel relacja n do m niska wydajnosc

moją odpowiedź w tamtym temacie już zapewne czytałeś, poza tym do skąplikowanych zapytań czy algorytmów to masz creole a nie propela (moja odpowiedź o 19/20 zapytań)... jeszcze jakieś wątpliwości?

pawel_k ma rację - trudno oczekiwać, że propel zrobi za ciebie wszystko łącznie z praniem. Propel ułatwi rzeczy powtarzalne i sprawi, że nie będziesz musiał zajmować się "bzdetami" tylko tymi rzeczami wymagającymi trochę inwencji.
Co do wydajności - propel demonem szybkości nie jest, ale jeśli piszesz mały system to to nie musisz się tym przejmować, a jeśli piszesz duży system, to zapewne taniej będzie kupić trochę ramu i wykorzystać jego możliwości. Używam tego narzędzia od relatywnie niedawna, ale jestem nim naprawdę zachwycony.

Ram czy lepszy procek nic nie da jak masz (ogolnie mówiąc) gorszą złożoność obliczeniową algorytmu.
Jesli propel ma powiedzmy (np w relacjach n-m) zlozonosc O(n^2) a normalnie mozna uzyskac O(n) to przy n rzedu 10^7 propel sie zawiesi chocbys mial nawet procka 10Ghz i 100GB ramu

po pierwsze jeśli pijesz do tematu który dzisiaj założył joebezucha to przejdź tam jeszcze raz i przeczytaj moją odpowiedź.
po drugie jeśli uważasz że lepiej optymalizować algorytmy (oczywiście te już dobrze zoptymalizowane) niż dokładać maszynę to jesteś w błędzie - wzmocnienie sprzętu daje nieporównywalnie większy wzrost wydajności.
po trzecie programowanie to nie tylko kod - to także ekonomia, a patrzenie przez program tylko z punktu technicznego jest mało profesjonalne.
po czwarte zachowujesz się jak troll do którego nie docierają żadne argumenty. powtórzę ostatni raz - w 19/20 przypadków propel w zupełności wystarczy, a do 1/20 przypadków masz creole. jeśli przez ten jeden przypadek chcesz tracić całą resztę funkcjonalności to pozostaje mi tylko współczuć podejścia...

stary wyluzuj

ok masz racje, ale


co do tego:
-jak są dobrze zoptymalizowane to sie ich nie optymalizuje (czyli optymalizuje sie zle zoptymalizowane) - np tak jak pisalem wczesniej - gdy zlozonosc jest istotnie gorsza - wtedy maszyna nic nie pomoze, naprawde !

taaa, znam maniaków którzy by chętnie robili wstawki z assemblera do php poza tym zawsze można optymalizować - zawsze może ktoś mieć dylemat czy stosować date() czy idate(), czy zamiast rand() stosować mt_rand(). dla mnie to bez sensu. co z tego że pracownik zrobi mi super wydajny kod i nagle odejdzie. nowa osoba przychodząc straci miesiąc czy dwa na naukę jego wypocin podczas gdy korzystając z frameworków nowy pracownik jest gotowy do wydajnej pracy po 2 dniach.

i co z tego że muszę włożyć kilka tysięcy w sprzęt - dokupując maszynę podnoszę granicę po przekroczeniu której aplikacja nie obsłuży już więcej użytkowników, podczas gdy optymalizacja kodu może tylko przekroczenie opóźnić (przy założeniu że cały czas się rozwijamy i zdobywamy nowych userów)

Naprawdę czepiasz się niepotrzebnie jednego, skrajnego przypadku. Zauważ że sami twórcy propela zdają sobie sprawę, że w pewnych przypadkach ich rozwiązanie może być nieoptymalne i dają ci wiele możliwości łącznie z ręcznym tworzeniem zapytań i wypełnianiem obiektów danymi. Jeśli chodzi o standardowe zapytania typu selecty z prostymi joinami itp to nie zrobisz tego bardziej optymalnie. Jedyne spowolnienie polega na tym, że parsowane jest więcej kodu (klasy propela).
Optymalizacja jest ważna - ale w moim przekonaniu chodzi o to, aby optymalizować tylko tam gdzie jest to konieczne - jeżeli mam osiągnąć 10-15% wzrostu wydajności a wymagać to ma 2 razy więcej pracy bo muszę zrezygnować z frameworków czy orm'ów to dziękuję - wolę przejrzysty, szybko napisany kod.