Кавычки в SQL запросах

[latmap]

Кавычки в SQL запросах

У меня есть класс работающий с базой данных. Он работает таким образом - я передаю в него массив полей БД, а на выходе получаю результат запроса.
Массив состоит из трех столбцов. Последний столбик обозначает условие, первый - параметр этого условия.
Т.е. получаем значения нужных полей у записи, где parent=33

$left_menu_print -> db_fields = Array(
	'id'			=>	Array( '', 0, 0),
	'priority'		=>	Array( '', 0, 0),
	'active_1'		=>	Array( '', 0, 0),	
	'created_1'	=>	Array( '', 0, 0),
	'title_1'		=>	Array( '', 1, 0),
	'parent'		=>	Array( '33', 0, 1),
);

Второй столбик меня волнует больше всего. Он нужен только для того, чтобы в SQL запросах расставлять кавычки у строковых значений, а там где численные значения - кавычки не ставим. Неужели без этого второго столбика никак не обойтись? Есть какой-то выход, а то он мне сильно жить мешает?

 

[zerkms]

откуда мы знаем, что за библиотеку для работы с БД ты используешь?

 

[latmap]

Ну я не настолько крут, чтобы использовать какие-то библиотеки. Я сам из этого массива потом получаю запрос примерно такого вида
SELECT id, priority, active_1, created_1, title_1 FROM shp_page WHERE parent=33

Т.е чтобы собрать запрос, мне приходится где-то ставить кавычки, а где-то нет. Для этого у меня и существует вторая колонка, от которой я горю желанием избавиться.

 

[Mols]

Ну вообще-то никто не мешает ставить кавычки везде.
И ничего в этом страшного нет.

 

[latmap]

Опаааааа. Приехали. Я в принципе догадывался, что я туплю, на не знал, что настолько.

Спасибо!

 

[dimagolov]

latmap, не слушай этого ламера. если "ничего не мешает", то это не значит, что так делать хорошо.

а хорошо указывать не 0/1, а, к примеру, константу, котораю определяет тип поля, MySQL_int, MySQL_char, etc., а при сборке запроса проверять на соответствие значения типу и в нужных случаях эскейпить, оборачивать в кавычки, при несоответствии же выбрасывать исключение.

 

[latmap]

dimagolov
Я так понимаю, что все равно тогда массив будет из 3-х столбцов? Или я что-то не догоняю?

 

[dimagolov]

ну тебе же нужно как-то связать поля с их типами? можешь хранить где-то массивы для каждой таблицы с типа field => type и при сборке искать допустимые поля и их типы в них, а не задавать каждый раз с данными, так даже лучше.

 

[latmap]

Ну понятно. Спасибо

 

[Фанат]

можно и не хранить, а получать на лету из структуры базы.

только одно важное дополнение.
кроме кавычек ты как-то еще эти поля обрабатываешь?

-~{}~ 12.03.10 08:44:

про условия я, кстати, вообще не понял. это для селекта, что ли, а не для апдейта?
а как ты записываешь больше-меньше?

 

[latmap]

кроме кавычек ты как-то еще эти поля обрабатываешь?

Не совсем понятно о чем тут идет речь. Наверное нет, не обрабатываю.

Этот массив я использую и для Select и для UPDATE и для REMOVE.

У меня тут всегда принято что условие будет "=". Если надо что-то другое - пишу руками отдельный запрос. Просто не хочется за собой постоянно таскать массив из трех столбцов, а тогда бы пришлось делать 4!

А каким образом тип можно получить из структуры базы? Какой функцией? И не будет ли это напрягать систему, если при каждом SQL запросе будет узнаваться тип каждого поля?

 

[Mols]

Автор оригинала: dimagolov
latmap, не слушай этого ламера. если "ничего не мешает", то это не значит, что так делать хорошо.

а хорошо указывать не 0/1, а, к примеру, константу, ..

Чушь полная.
Довольно распространённая практика - ескейпить все и всё закрывать кавычками.
Это ничему не мешает.
Можно ради каких-то внутренних убеждений конечно отделять числа и строки(когда то я кстати тоже так делал) - но смысла в этом (по крайнем мере для МуСКЛ) - нет.
Насчет хорошо или плохо - читайте вопрос перед тем как высказываться.
Такого вопроса здесь не стояло.
На мой(субъективный) взгляд лучше вообще использовать PDO и биндить значения.
Кстати уважаемый "гуру" - если вы помните документацию -то методы PDOStatement->bindValue и т.п. имеют третьим НЕОБЯЗЯТЕЛЬНЫМ параметром тип передаваемых данных. И по умолчанию используется именно строковый тип. То есть разработчики PDO считают вполне нормальным работать со всеми входящими параметрами как со строками.
Кроме того - константы параметров PDO вообще не содержат значений для типов с плавающей точкой. То есть такие типы вообще можно передать только строкой. Сомневаюсь, что Вы более компетентны чем разработчики PHP.
Поэтому я Вас прошу, перед тем как кого-то называть ламером - смотрите в зеркало и будьте скромнее.

-~{}~ 12.03.10 09:59:

P.S. NULL - исключение. Его конечно не надо заворачивать в кавычки.

 

[Single]

P.S. NULL - исключение. Его конечно не надо заворачивать в кавычки.

а SQL функции?

 

[Фанат]

latmap
честно говоря, я сначала не понял, что делает твоя библиотека.
как-то мне странно видеть в одном и том же массиве как просто список поле для вывода, так и условия для WHERE.
Но это ладно. Ты саказал, что то же самое используется и для UPDATE. Можно посмотреть код, который формирует такой запрос? Тогда разговор будет более предметным.

-~{}~ 12.03.10 11:47:

В любом случае, данная формулировка вопроса кажется мне надуманной.
Если уж мы таскаем за собой массив аж из 3 столбцов, то горевать еще об одном не вижу никакого смысла.

 

[latmap]

Автор оригинала: *****
Ты саказал, что то же самое используется и для UPDATE. Можно посмотреть код, который формирует такой запрос? Тогда разговор будет более предметным.

	    function update_record( $received_db_fields, $table, $query_advanced="" ) {

			$query = "UPDATE " . $this->variables['prefix'] . $table . " SET ";
			
			foreach($received_db_fields as $index => $val) 
				if ( $val[2] == 0 )
					if ( $val[1] == 1 ) $query .= $index . "='" .  $this->qstr($val[0], magic_quotes_runtime())  . "', ";	
					else 
						if ( $val[0] !== "" ) $query .= $index . "=" . $this->qstr($val[0], magic_quotes_runtime()) . ", ";
			
			$query = substr($query, 0, strlen($query) - 2); // stiraem poslednuju zapjatuju i probel			
			$query .= " WHERE ";
			
			foreach($received_db_fields as $index => $val) 
				if ( $val[2] == 1 )
					if ( $val[1] == 1 ) $query .= $index . "='" .  $this->qstr($val[0], magic_quotes_runtime())  . "' AND ";	
					else 
						if ( $val[0] != "" ) $query .= $index . "=" . $this->qstr($val[0], magic_quotes_runtime()) . " AND ";
			
			$query = substr($query, 0, strlen($query) - 4); // stiraem poslednij AND i probel
			$query .= ' ' . $query_advanced . ';';

			mysql_query($query);
			
			//print_r($received_db_fields);
			//echo $query;
			
	    }

 

[fixxxer]

Mols

Я так понимаю, работал ты только с MySQL, с нормальными СУБД не сталкивался?

 

[Фанат]

а что делает функция magic_quotes_runtime()?
и qstr заодно

 

[latmap]

qstr ставит косую черту перед кавычками, еслитаковые попадают в запрос, грубо говоря. Там не маленькая такая функция. Где-то подглядел. magic_quotes_runtime для этого же.

 

[Single]

// stiraem poslednuju zapjatuju i probel
// stiraem poslednij AND i probel

с [m]join[/m] будет более читабельно.

и да, если уж у тебя есть некое подобие sql конструктора в виде твоего массива почему бы в него не добавить еще один элемент для where блока с указанием типа условия отличного от AND?

qstr ставит косую черту перед кавычками, еслитаковые попадают в запрос, грубо говоря.

[m]mysql_real_escape_string[/m]

PS. MySQL. Просто и понятно.

 

[Mols]

Single
СКЛ функции тоже нормально отработают если туда передать число в кавычках. (опять же в мускле -100%)

fixxxer
Ну по сути да. Не могу сказать, что имею большой опыт работы с другими СУБД. Небольшой опыт работы есть с ПГ. Насколько я помню так числа в кавычках не вызывают никаких сложностей. Афаик в ПГ есть особенность эскейпа для бинарного типа. Вопрос востребованности этого дела у меня остался открытым. Хранить бинарники в БД... Ну не знаю. Опять же может кому-то и надо но мне пока не надо. Если же речь о каких-то сложных/нестандартных (например пользовательских) типах - опять же это другой вопрос. Тут же речь идет строка/не строка. Да и просто подавляющее большинство задач не требует никаких особенных типов.