Несколько функций для работы с базой данных (PHP)

Все мы, старые веб-программисты, с детства помним примеры работы с базами данных из справочника php_manual_ru:

<?php mysql_connect("localhost", "mysql_user", "mysql_password") or die("Could not connect: " . mysql_error()); mysql_query("USE `mydb`"); mysql_query("SET NAMES cp1251"); $result = mysql_query("SELECT `name`, `status` FROM `users`"); while ($line = mysql_fetch_assoc($result)) { echo "<p>user_name: {$line['name']}, status: {$line['status']}</p>"; }

А может, уже и не помним, замороченные всякими PEAR && PDO. Но иногда вспоминаем, как трудно было работать с "голым" PHP из справочника. А теперь вот мне захотелось понять, почему же это было так трудно – работать, следуя справочному руководству разработчиков PHP.

Ответ, в общем-то, заранее известен, и он достаточно прост: все проблемы в программировании возникают от непоследовательности. Приведённый пример из справочника плох тем, что он изначально закладывает кривой фундамент в код начинающего программиста. Почему вызов первой функции примера (mysql_connect) обрабатывается на предмет ошибки (mysql_error), а все остальные функции – нет?

Допустим, соединились мы с БД успешно, и даже случайно там оказалась таблица "users", но в этой таблице, например, нет поля "status". Что мы получим на экране? Кучу строк с сообщением об одной и той же ошибке. Поэтому крутые гуру говорят: всегда отключайте вывод ошибок на экран (ini_set("display_errors", false);). Но другие крутые гуру так же страстно призывают не скрывать никакие ошибки. И покорные ученики выбирают худшее из зол – золотую середину, в половине случаев выводя ошибки, а в половине пряча с помощью @ ("собаки").

Между тем, строго последовательные (пусть даже выглядящие иногда тупыми) действия делают программирования простым и приятным. Пример из руководства в одном из крайних выражений последовательности можно переписать так:

<title>test_db</title> <h2>test_db</h2> <?php @mysql_connect("localhost", "mysql_user", "mysql_password"); @mysql_query("USE `mydb`"); @mysql_query("SET NAMES cp1251"); $result = @mysql_query("SELECT `name`, `status` FROM `users`"); while ($line = @mysql_fetch_assoc($result)) { echo "<p>user_name: {$line['name']}, status: {$line['status']}</p>"; }

И нам уже неважно, существуют БД и таблица или нет, мы спокойны, потому что пользователь никогда не увидит никакой ошибки. Ну, в крайнем случае, будет страница, состоящая из одного заголовка, ну ничего ведь страшного?

Можно запрограммировать всё, весь сайт в таком стиле. И, теоретически, такой сайт может работать вечно. Но теория суха, а жизнь всё время меняется (даже в песне поётся: "Перемен! Жизнь требует перемен!"). Жизнь заставит вас рано или поздно перенести сайт на другой хостинг. Или добавить в таблицу ещё одно поле. Или ещё что-нибудь поменять. И тогда вам придётся чертыхаться, кляня себя за старательно расставленные повсюду "собаки".

Разделяй и властвуй

Удобная и приятная работа с сайтом целиком зависит от правильного деления задач на блоки (или наоборот, объединения в блоки). Важно также, в каком направлении делить, в каком разрезе (вдоль или поперёк).

Первое деление (которое, собственно, и порождает часто непоследовательность) – решить, чья это задача, кто будет её давать программе и читать потом сообщения об ошибках. Обычно таких командира бывает два: пользователь и программист. Пользователь, например, ставит программе задачу "проверить мой пароль", и должен получать от программы сообщения о своих ошибках – например, "в пароле должны быть только латинские буквы и цифры". А программист ставит, например, задачу "работать с БД `mybd`", и должен получать сообщения об ошибках вида "Unknown database 'mybd'".

Иногда у пользователя бывает возможность самому установить какую-то базу данных на сайт (например, в проекте "Инфодиск"). Тогда он соответственно своей возможности тоже должен видеть ошибку (заботливо переведённую программистом на русский язык) "База данных `mybd` не установлена". Вопрос, должен ли пользователь видеть ошибки программиста, неоднозначен и часто зависит от заказчика сайта. Но мы отвечаем на него просто: ошибки программиста обычно фатальны (сайт вообще не работает), поэтому их надо показывать всегда – немного непонятной информации на английском языке лучше полного отсутствия информации (чисто белой страницы).

Следующая отделяемая часть известна всем: это подключение к mysql. Обычно это действие выносят в отдельный файл (config.php, connect.php...), подключаемый к основным скриптам через include. В большинстве случаев туда же можно отнести и выбор текущей БД (ну, и установить кодировку до кучи):

mysql_connect("localhost", "mysql_user", "mysql_password") or exit(mysql_error()); mysql_select_db('mydb') or exit(mysql_error()); mysql_query("SET NAMES cp1251") or exit(mysql_error());

Дальнейшее разделение задач при работе с БД является полнейшим произволом программиста. Мечтой веб-мастера является функция sql2page($sql), принимающая в качестве параметра sql-запрос и возвращающая готовую HTML-страницу. Но даже такая функция не была бы конечной и самодостаточной, хотя бы потому что sql-запрос не является константой, а при каждом вызове скрипта должен быть аккуратно сконструирован при помощи каких-то других функций.

Конструирование запроса мы рассмотрим ниже. А сейчас – разделение внутри sql2page. Ясно ведь, что такая волшебная функция не может быть простой. Внутри неё обычно используют отдельный блок – другую функцию с mysql_fetch_assoc(), превращающую ресурс, возвращаемый запросом, в (более удобный?) массив. Это не всегда очевидное разделение: зачем проходить в цикле ресурс mysql, превращая ресурс в массив, а потом ещё раз в цикле обрабатывать массив?

Если, например, ресурс большой по объёму (100К) и просто содержит данные, которые надо один раз вывести на страницу, это явно неоптимально – два раза проходить большой цикл. Но если надо получить одну «ячейку» таблицы (например, количество записей – по запросу вида select count(*) from `user`), ясно, что функция, превращающая sql-запрос в значение, здесь бы очень упростила работу. Другая причина – неоднократное использование результатов запроса (в этом случае тоже оптимальнее быстро «перекачать» ресурс в массив и дальше работать с массивом).

Здесь на сцену незаметно выходит ещё одна дилемма – «об оптимальности». На самом деле даже целый класс дилемм, которые не всегда легко разглядеть, но которые всё равно давят на нас, даже неявно:

1. Скорость написания – скорость чтения кода (удобочитаемый код надо дольше писать).
2. Скорость чтения интерпретатором – скорость чтения человеком.
3. Скорость чтения (интерпретатором) – скорость исполнения.
4. Сложность структуры кода – расширяемость приложения.

Это достаточно приблизительные метки. Можно, например, ещё смотреть на проблему под углом длины кода (чем длиннее код, тем он... читаемее? быстрее работает?.. – или "более удобный для человека код должен быть более длинным"?).

Собственно sql

Исходя из всех (или части?) этих пересекающихся дилемм, мы для начала отделили сам момент получения sql-ресурса, приблизительно в такую функцию:

function sql_get_resource($sql, $skip_err = false) { $r = mysql_query($sql); $err = mysql_error(); if ($err) { $n = false; if (!$skip_err) exit("<br> $sql;<br>$err<br> "); else $r = $err; } else $n = (is_resource($r)) ? mysql_num_rows($r) : false; return array($r, $n); }

Удобство такого деления мы видим вот в чём:

1. При обработке sql-ресурса всегда проверяется количество возвращаемых строк (mysql_num_rows) – разумно это обобщить, выделить в функцию.
2. Мы не знаем заранее, как лучше выдать результаты sql-запроса – сразу в виде готового HTML, или предварительно переведя в массив. Если сразу, функцию sql_get_resource будет использовать функция визуализации; если сначала нам нужен массив, функцию sql_get_resource будет использовать функция sql_select_col или ещё какая-нибудь sql_select_cell (хотя в последнем случае возвращается не массив, а строка).
3. Функция всегда возвращает количество строк ресурса (даже если ресурса нет): если это значение равно false, в первом элементе возвращаемого массива можно попытаться прочитать сообщение об ошибке (или просто игнорировать дальнейшую обработку); если количество строк равно нулю, ресурс нормальный (можно, например, работать с наименованиями полей sql-таблицы), но данных для вывода (на экран или ещё куда) не содержит.

Функция получения массива из одной колонки таблицы sql_select_col – одна из самых простых и приятных. Особенно если у нас уже есть функция sql_get_resource :-):

function sql_select_col($sql, $skip_err = false) { $arr = array(); $r = sql_get_resource($sql, $skip_err); if ($r[1]) { while($row = mysql_fetch_row($r[0])) { $arr[] = $row[0]; } } return $arr; }

Ещё проще будет sql_select_cell, так что о ней здесь даже и говорить смешно. Остальные функции (получения одной строки и получения многих строк) усложняются вполне предсказуемо.

До отправки запроса (конструирование sql)

Возьмём простой скрипт, которому пользователь передаёт параметры через url (GET). Например, скрипт авторизации с url вида auth.php?user=me&pw=123. Что самое очевидное, что должен сделать программист при передаче GET-параметров в sql? Дружный хор мастеров утверждает, что это защита от инъекций: что-нибудь вида $pw = mysql_real_escape_string($_GET['pw']), ну, или уж никак не меньше, чем !addslashes!. И этот совет, в отрыве от реального контекста, способен создать начинающему веб-разработчику не меньше проблем, чем атаки гипотетических хакеров.

Суровая реальность заключается в том, что на хостинге в настройках PHP может стоять !magic_quotes_gpc = on!, а начинающий (да и заканчивающий) программист может не знать (да и не очень обязан знать), что эту настройку во время исполнения скрипта изменить !нельзя! (!). Так простой на первый взгляд addslashes превращается в отдельную пользовательскую функцию:

function check_gpc($val) { if (get_magic_quotes_gpc()) $val = stripslashes($val); return mysql_real_escape_string($val); }

Далее, на том или ином этапе обязательно присустствует проверка существования входящих параметров (isset($_GET['pw'])). Она усложнаяется тем, что мы не знаем заранее, что может прийти в $_GET. Но мы знаем, что нам надо для данного скрипта – отсюда возникает другой вариант проверки magic_quotes_gpc:

function check_GET($arr) { $res = array(); foreach($arr as $v) { if (array_key_exists($v, $_GET)) { if (!$_GET[$v]) return false; $res[$v] = (get_magic_quotes_gpc()) ? stripslashes($_GET[$v]) : $_GET[$v]; } } return $res; }

На входе эта функция в качестве параметра получает массив, состоящий из наименований (индексов), которые мы хотели бы получить из $_GET. Если хотя бы одно значение отсутствует, фукнция возвращает false. Если всё в порядке, можно передавать результат дальше для генерации sql-запроса. Откуда-то мы (наш скрипт) уже узнали, из какой таблицы и какие брать данные. Теперь вот ещё знаем, по каким полям и значениям производить отбор. Всё вместе – выйдет нечто вроде:

SELECT `name`, `status` FROM `users` $wherestr,

где $wherestr сгенерировано ещё одной функцией:

function build_where($arr, $nowhere = false){ $wherestr = ''; if (!is_array($where)) return $wherestr; $comma = ''; foreach($where as $key => $val) { if (is_array($val)) { $value = (isset($val['value'])) ? $val['value'] : $val; $case = (isset($val['case'])) ? sql_set_value($val['case'], "") : '='; } else { $value = $val; $case = '='; } $value = sql_set_value($value, "'"); $field = mysql_real_escape_string($key); $wherestr .= "{$comma}`$field` {$case} $value"; $comma = ' AND '; } $where_slovo = ($nowhere === false) ? 'WHERE ' : ''; $wherestr = ($wherestr) ? " {$where_slovo}($wherestr) " : ''; return $wherestr; }

Н-да. И ещё одна функция понадобится:

function sql_set_value($val, $quot) { $v = false; if (is_array($val) && isset($val['func'])) { $v = "{$val['func']}("; $comma = ''; foreach($val['param'] as $p) { $quot = (isset($p[1])) ? $p[1] : ''; $par = mysql_real_escape_string($p[0]); $v .= "$comma{$quot}$par{$quot}"; $comma = ', '; } $v .= ")"; } else { $v = mysql_real_escape_string($val); $v = "{$quot}$v{$quot}"; } return $v; }

Чем дальше, тем, блин больше. На... зачем, спрашивается, такие сложные функции, там, где можно было бы обойтись простым выражением:

"... AND " . addslashes($key) . "='" . addslashes($value) . "'";

А вот зачем: чтобы в WHERE могло попасть выражение вида "WHERE pw=old_password('123')", то есть с функцией MySQL (а вы думали так всё просто будет?).

Ну, зато со всеми нужными функциями сам действующий скрипт будет состоять всего из 15-ти строк. Вот он: http://ir2.ru/test_auth.php.gz. А вот несколько тестовых ссылок:

1. http://ir2.ru/test_auth.php?pw=123
2. http://ir2.ru/test_auth.php?pw=123&name=mi
3. http://ir2.ru/test_auth.php?pw=123&name=me

С этого момента, собственно, только и начинается настоящая работа. Ведь это, например, совсем не царское дело – помнить, где какой old_password при генерации WHERE подрисовывать. Надо для начала хотя бы собрать сведения обо всех полях всех таблиц сайта и занести в специальную таблицу. А потом, при составлении массива WHERE извлекать нужные сведения о полях из сделанной спецтаблицы. Нужно учесть также, что, например, дата из привычного нам формата dd.mm.yy в MySQL должна превращаться в YYYY-mm-dd. После этого можно уже будет, пожалуй, переходить и к основной части: постраничному выводу информации из больших таблиц, организации поиска на сайте, организации добавления новой информации...

D.M., admin

Читать все комментарии (0)

Добавить комментарий:

*Автор:
E-Mail:
*Текст: