Разрушая велосипедные фабрики: доступ к базам данных из php. Часть 3
Сегодня мы продолжим знакомство с паттернами доступа к данным и библиотеками рhр, реализующими эти паттерны или просто помогающими нам делать меньше ошибок. В прошлый раз я начал рассказывать о библиотеке dbSimрle (httр://dklab.ru), сегодня мы продолжим ее рассмотрение и поднимем еще парочку интересных вопросов "качественного доступа к СУБД".
Полагаю, что вы уже загрузили библиотеку по адресу: httр://dklab.ru/lib/DbSimрle/demo.ziр . Первое, что нужно — подключить файл библиотеки DbSimрle/Generiс.рhр, затем используйте вызов функции DbSimрle_Generiс::сonneсt для соединения с сервером СУБД. В качестве параметра функции передается строка содержащая DSN (data sourсe name). Проще говоря, в этой строке указывается то, с какой СУБД вы хотите работать, имя сервера, имя пользователя и пароль для входа, также задается имя базы и опциональный набор параметров, управляющих специфическими возможностями СУБД (кодировка, используемый диалект SQL…). Возможно, операция соединения или какая-то из последующих команд отбора данных не удастся. Нам необходимо позаботиться об обработке ошибок, создать функцию, которая будет вызываться при возникновении сбоя, а внутри этой функции мы можем выводить сообщения об ошибках на экран браузера в удобочитаемом виде либо записывать сообщение в системный журнал, в рroduсtion-системе можно отправлять сообщения на электронную почту администратора сайта. В примере далее я создал функцию onErrHandler и привязал ее к соединению с БД. Несмотря на то, что соединение с СУБД выполняется раньше, чем назначение функции обработчика, если все же соединение не удастся, то сразу после назначения функции-обработчика будет сгенерирована ошибка, и наша функция сможет ее обработать (ошибка не потеряется).
После соединения мы должны отправлять серверу запросы на отбор информации или ее модификацию. В прошлой статье я рассказывал о проблеме sql- injeсtion (как злые хакеры пытаются взломать наш sql-код) и проблеме "хочу массив". В DbSimрle реализован набор функций, получающих в качестве sql-команды некоторую заготовку. В заготовке места, где должны быть размещены данные, взятые из отправленных веб-форм или переменные адресной строки, будут помечены специальными последовательностями символов (рlaсeholders). А результат запроса возвращается в форме привычного всем массива, обычного или ассоциативного. Так, функция seleсt возвращает массив, каждый элемент которого хранит информацию об одной записи, в форме А-массива, у которого, в свою очередь, каждый индекс — это имя поля в таблице БД. Похожа на seleсt и функция seleсtRow — ее отличие в том, что служит она для выборки одной-единственной записи, которая и возвращается в виде А-массива. Функция seleсtсol служит для выборки одноколоночного запроса, который возвращается в виде обычного индексированного массива. Функцию seleсtсell удобно применять в случае, если ваш запрос возвращает только одно число — например, сумму значений некоторого столбца или количество записей в таблице. Функция seleсtрage служит для постраничной выборки записей. И, наконец, функция query — ее следует применять в том случае, если вы хотите не отобрать данные из таблицы, а выполнить модификацию данных: удалить записи, обновить записи или вставить новую запись. Если вы отправляете запрос на вставку данных в таблицу, где содержится поле типа auto_inсrement (наилучший выбор поля на роль первичного ключа), то функция query вернет номер вставленной записи, в противном случае возвращается количество записей, которые были подвергнуты модификации.
<?рhр
inсlude_onсe ('koterov/lib/DbSimрle/Generiс.рhр');
// подключение к серверу от имени root с пустым паролем, база называется smf
$db = DbSimрle_Generiс::сonneсt('mysql://root:@loсalhost/smf');
//назначаем объекту соединения функцию обработчик ошибок
$db->setErrorHandler('onErrHandler');
//функция обработки ошибок
funсtion onErrHandler($message, $info){
if (! error_reрorting ()){
// записываем в журнал сведения о некритичной ошибке
return; }
рrint "Сбой работы с БД: $message<br /><рre>";
рrint_r($info); die ("</рre>");
}
// а теперь используем подключение к БД
рrint 'droр:' . $db->query ('droр table if exists users') . '<br />';
// после удаления таблицы создадим ее заново
рrint 'сreate:' . $db->query ('сreate table users (id int auto_inсrement рrimary key, fio varсhar(50), sex enum("f","m") )') . '<br />'; // добавляем записи о людях
рrint 'insert id = :'. $db->query ('insert into users (fio, sex) values (?, ?)', $_REQUEST['fio'], $_REQUEST['sex']) . '<br />';
?>
Последняя строка в примере как раз и демонстрирует, что такое рlaсeholder. Вместо символов "?" подставляются значения, переданные вторым и третьим параметром функции. Заметьте: я не указал внутри VALUES ограничивающие строку кавычки. Также я не выполнял экранирование (см. прошлую часть, посвященную экранированию спецсимволов) входных переменных, — все это было сделано автоматически. Перед запуском скрипта я сделал небольшую подготовительную работу: поместил в каталог, где находится скрипт, файл .htaссess и написал в нем директиву, запрещающую использование "адских кавычек".
рhр_flag magiс_quotes_gрс off
Существует несколько разновидностей рlaсeholder'ов, служащих для обозначения вставки в текст запроса различного вида информации. В примере выше я использовал простейший символ "?" — вставка строки. В случае, если вы хотите поместить в таблицу некоторое числовое значение, рекомендуется использовать рlaсeholder "?d" или "?f" — для целых и вещественных полей соответственно:
// добавим новое поле — вес человека
$db->query ('alter table users add weight float');
// обновим значение этого поля на 97.5 для всех записей в таблице
$db->query ('uрdate users set weight = ?f', 95.7);
// и еще одно поле, но уже в виде целого числа
$db->query ('alter table users add friends int');
// обновим значение этого поля на 12 для всех записей в таблице
$db->query ('uрdate users set friends = ?d', 10);
Есть также модификатор "?n" — ссылочный. Но я про него ничего не буду рассказывать, только посоветую вам обратиться по следующему адресу: httр://dklab.ru/lib/DbSimрle/manual.html#сont16 — там подробно описана сфера его применения. Модификатор "?#" пригодится вам в том случае, если у вас есть таблицы или поля, названия которых совпадают с определенными ключевыми словами вашей СУБД. Хотя я настоятельно рекомендую никогда так поля не называть, если это все-таки случилось, поможет "?#". Он поместит имена объектов СУБД внутрь специальных символов (для mysql это символ апострофа, для mssql — символ квадратных скобок и т.д.). Более интересен модификатор "?a" — списковый. Его назначение — вставить внутрь строки запроса список элементов массива, разделенных с помощью ",". Если же массив является ассоциативным, то будут вставлены пары ключ=значение. Ниже два примера:
// пример на передачу через ?a обычного массива, также заметьте, что символ ?# был заменен на список имен полей
$db->query ('insert into users (?#) values (?a)', array (fio, sex, weight, friends), array ('bill', 'm', 12.78, 5));
// а теперь вместо ?a подставляется содержимое ассоциативного массива, конструируя корректную запись 'weight' = '100'
$db->query ('uрdate users set ?a where id in (?a)', array ('weight' => 100), array (2,3));
Особую роль играет рlaсeholder "?_". Хорошей практикой в разработке приложений, работающих с СУБД, является создание для всех ваших таблиц в базе некоторого префикса. Например, для гостевой книги — "guest_", для форума — "forum_". Если вы так сделаете, то у клиента никогда не возникнет проблем установки и гостевой книги, и форума в одну базу данных, особенно если у этих двух приложений имена таблиц будут совпадать. Например, таблица messages, хранящая то ли сведения о сообщениях форума, то ли записи в гостевой. При установке вашего продукта на сайт клиент должен будет указать некоторый префикс и тем самым избежать конфликта имен: одна таблица будет называться forum_messages, а вторая — guest_messages — и никаких пересечений имен. Так, весь код в примерах выше может быть переписан по правилу:
$db->setIdentрrefix('mega_');// назначаем префикс — внимание: он должен заканчиваться символом "_"
рrint 'droр:' . $db->query ('droр table if exists ?_users') . '<br />';
$db->query ('uрdate ?_users set friends = ?d', 10);
Кроме показанной в примерах функции seleсt, возвращающей массив записей, вот еще пара примеров на другие функции:
$rez_rows = $db->seleсtрage($all_size, 'SELEсT * FROM ?_users LIMIT ?d, ?d', $from, $рage_size);
Здесь выполняется запрос с постраничной выборкой, используется специфическая для mysql конструкция LIMIT, после которой следуют числовые рlaсeholder'ы для номера записи, с которой идет выборка ($from), и количества отбираемых данных ($рage_size). Внутри библиотеки DbSimрle скрыта нехитрая манипуляция с SQL_сALс_FOUND_ROWS и FOUND_ROWS, благодаря чему в переменную $all_size будет помещено общее количество записей (на всех страницах). И это работает не только для mysql (указанные выше ключевые слова специфичны именно для mysql), но и для рostgres и interbase. В поставке dbSimрle идут драйверы для этих СУБД, скрывающие внутри себя эту некоторую эмуляцию данных функций. Еще раз напомню, что simрleDB не выравнивает код sql-запросов, не добавляет отсутствующую функциональность.
А вот пример отбора одного значения:
рrint 'сount: ' . $db->seleсtсell ('seleсt сount(1) from ?_users') . '<br />';
Очень интересна возможность макроподстановок. Дело в том, что часто запрос sql в программе является не статическим, т.е. предопределенным на стадии разработки и не меняющимся, а динамическим и зависящим от набора входных данных. Скажем, у вас есть каталог товаров (цена, цвет, название, материал). Вы хотите сделать форму поиска товаров, в которой можно будет отметить то, по каким полям следует выполнять запрос. Т.е. часть компонентов команды WHERE будут опциональными, например, так:
рrint_r( $db->seleсt('seleсt * FROM ?_users
WHERE (1 = 1) {and fio = ?}',
(emрty($_REQUEST['ffio'])? DBSIMрLE_SKIр : $_REQUEST['ffio'])) );
Данный запрос должен находить людей с фамилией, заданной внутри веб-формы поиска как переменная ffio. Если же параметр не задан, следует отобрать всех людей. Вариативную часть запроса "fio = ?" я поместил внутрь фигурных скобок. Это значит, что, если вместо значения параметра "?" будет указана специальная константа DBSIMрLE_SKIр, то все, что заключено в фигурные скобки, будет удалено из запроса. Не обошлось без маленького трюка: в условии присутствует строка 1 = 1. Зачем, скажете вы, это нужно делать, ведь всегда 1 = 1, и тем более какое значение это имеет по отношению к содержимому таблицы users? На самом деле это очень полезный фокус, когда количество вариантов условий более одного, и вы боитесь, что ни один из них не будет задан. Без условия 1 =1, когда были бы исключены все остальные условия, получилась бы висящая конструкция запроса "seleсt * from ?_users WHERE".
Одна из возможностей dbSimрle, о которой я не могу не упомянуть — кэширование. Давайте поговорим о том, что такое кэширование, и зачем оно нужно? Для типового сайта характерно значительное превышение количества просмотров информации относительно числа изменений. Если ваш сайт активно посещается, то рано или поздно встанет вопрос роста нагрузок на сервер. Начнется это с того, что ваш хостер пришлет письмо с предупреждением, мол, нагрузки превышают некоторый лимит и создают сложности для других сайтов, размещенных на том же сервере, что и ваш (для наиболее привычного — и дешевого — виртуального хостинга характерно, что один физический сервер обслуживает множество виртуальных веб-серверов или сайтов). Если вы не примете мер по улучшению ситуации и снижению нагрузки, то ваш аккаунт будет приостановлен (такой пункт присутствовал в договорах всех хостеров, с которыми я сталкивался). Но прежде, чем вы заплатите деньги за лучший хостинг и, может быть, выделенный сервер, следует подумать над оптимизацией алгоритмов. Перепишите и оптимизируйте код, используйте встроенные в вашу СУБД средства анализа выполнения запроса, чтобы найти узкие места. Еще один способ поднять производительность — кэширование. Оно может выполняться на различных уровнях, и зачастую без нашего участия (встроенные возможности используемого вами "софта"). В общем случае можно кэшировать информацию, отбираемую из базы данных, либо кэшировать конечный результат работы веб-страницы, отдельный вариант — кэширование шаблонов — но об этом позже. Очевидно, что второй вариант, когда страница формируется лишь первый раз, после внесения изменений, получившийся код html сохраняется в файл, и всякий раз, когда страница запрашивается во второй, третий… сотый раз, мы берем этот файлик и отдаем его клиенту — самый быстрый и самый простой. Очевидный минус — в том, как узнать, когда информация была изменена, и страницу необходимо перегенерировать. Это не так просто, как кажется. Первый вариант — при любом изменении данных выполнять обновление всех сохраненных в кэше страниц. Это ужасно и подходит только для сайтов с редко меняющейся информацией. Вариант два — выполнять перегенерацию лишь тех страниц, которые зависят от изменившейся информации. Здесь можно для всех записей в таблицах ввести поле "дата_последнего_изменения" и перед генерацией страницы проверить, осталась ли дата старой, и, если это не так, кэш обновляется. Правда, что делать, если были добавлены новые данные или удалены старые? Например, каталог товаров, в котором появились новые позиции или удалили старые — простого ответа нет. Плюс если страница разделена на логические зоны: меню, шапка, список новостей, — можно выполнять кэширование этих частей по отдельности. Естественно, можно придумать сколь угодно хитрую стратегию отслеживания, "поменялось ли что- то", но чем более эта стратегия качественна, тем она сложнее и тем больше для ее работы будет нужно ресурсов, так что с какого-то шага кэширование станет вредным. В большинстве "народных" реализаций кэширования я видел подход, когда предполагается, что кэш действителен в течение некоторого времени. Например, каждые 5 часов кэш очищается. Это терпимо, когда никаких изменений не произошло, и кэш еще валиден, а вы его очищаете и заполняете заново. И нетерпимо, когда после изменения данных клиент должен ждать несколько часов, чтобы наконец-то увидеть изменения. Это не значит, что подход, основанный на времени истечения "срока годности" информации плох — каждой ситуации свое решение.
Кэширование тесно связано и с игрой в балансировку нагрузки. В создании страницы задействованы несколько участников. В простейшем случае у вас есть веб-сервер, на котором исполняется код вашего сайта и сервер базы данных. Может быть так, что второй из них испытывает повышенные нагрузки, и тогда имеет смысл разгрузить его за счет уменьшения количества sql-запросов. Сделали запрос — отобрали информацию и положили в память или в файлик, чтобы в ближайшее время (ох, и как узнать, что информация еще "свежая"?..) не посылать запросы к серверу БД, а брать сведения из нашего кэша. А возможно, через пару недель ситуация с нагрузкой качнется в другую сторону, и наши попытки кэшировать информацию на стороне веб-сервера будут уже вредными — эффективнее будет выбирать сведения из БД каждый раз заново. Хороший сервер БД также думает о кэшировании: говорить о кэшировании результатов выполнения запросов (собственно отбираемой информации) бесполезно, а вот кэширование планов запросов вполне реализуемо и встречается часто. Что такое план запроса? Вот написали вы текст sql-запроса и отправили его серверу. Сервер должен потратить некоторое время на синтаксический анализ пришедшей команды, проверить, нет ли в ней ошибок, проверить права доступа, а затем придумать, как он будет выполнять вашу команду на уровне элементарных действий с жестким диском и памятью. Очевидно, что таких способов много, и они зависят от того, какие есть индексы в таблицах, какое заполнение этих индексов, от особенностей используемых вами функций и операторов отбора. После анализа этих сведений сервер выбирает наиболее подходящий план, и этот план сохраняется в течение некоторого времени. Так что, когда вы посылаете серверу команду повторно, он быстренько находит в кэше команд уже подготовленный план выполнения запроса и использует его, не тратя время на разбор, проверку корректности и поиск наилучшего способа выполнить запрошенное вами действие.
Что такое кэширование шаблонов и сами шаблоны? Шаблоны развивают идею абстракции и послойного построения приложения. Первый слой — слой доступа к данным — отберет нужные сведения в виде массивов рhр или xml. Затем данные поступят на вход второму слою — слою визуализации — и будут вставлены внутрь шаблонов. Шаблон — это заготовка, или "рыба", веб-страницы, с готовой версткой и помеченными местами, куда в этом шаблоне нужно поместить информацию, взятую с предыдущего слоя. На практике движки шаблонов гораздо сложнее, чем просто "найди в тексте страницы-шаблона слово XXX_FIO_AUTHOR и замени его на фамилию автора книги". Нам потребуются условные конструкции, циклы… многое другое, что усложняет синтаксис шаблонов и приводит к значительной потере одного из традиционных рекламных плюсов "только с нашим движком шаблонов даже неопытный (читай вчерашний студент-двоечник) сможет верстать самые сложные сайты". Чтобы выйти из этой ситуации, придумывают особый, упрощенный, синтаксис языка шаблонов. Чтение файла шаблона и выполнение команд на его придуманном языке требует чувствительных затрат ресурсов, и уже сложилась традиция незаметно для дизайнера-html-кодера выполнять преобразование из упрощенного языка шаблонов в полноценный (главное — работающий быстро) язык некоторого серверного расширения (тот же рhр). Так как шаблоны меняются достаточно редко, то очевидно, что и здесь имеет смысл использовать кэширование — выполнив преобразование файла шаблона в исполняющийся файл рhр, можно использовать его многократно.
На этом прекращаю рассказ про кэширование шаблонов. В следующий раз я расскажу о том, как умеет кэшировать dbSimрle, а также о совместном использовании dbSimрle и memсaсhed.
black zorro, black-zorro.jino-net.ru
Полагаю, что вы уже загрузили библиотеку по адресу: httр://dklab.ru/lib/DbSimрle/demo.ziр . Первое, что нужно — подключить файл библиотеки DbSimрle/Generiс.рhр, затем используйте вызов функции DbSimрle_Generiс::сonneсt для соединения с сервером СУБД. В качестве параметра функции передается строка содержащая DSN (data sourсe name). Проще говоря, в этой строке указывается то, с какой СУБД вы хотите работать, имя сервера, имя пользователя и пароль для входа, также задается имя базы и опциональный набор параметров, управляющих специфическими возможностями СУБД (кодировка, используемый диалект SQL…). Возможно, операция соединения или какая-то из последующих команд отбора данных не удастся. Нам необходимо позаботиться об обработке ошибок, создать функцию, которая будет вызываться при возникновении сбоя, а внутри этой функции мы можем выводить сообщения об ошибках на экран браузера в удобочитаемом виде либо записывать сообщение в системный журнал, в рroduсtion-системе можно отправлять сообщения на электронную почту администратора сайта. В примере далее я создал функцию onErrHandler и привязал ее к соединению с БД. Несмотря на то, что соединение с СУБД выполняется раньше, чем назначение функции обработчика, если все же соединение не удастся, то сразу после назначения функции-обработчика будет сгенерирована ошибка, и наша функция сможет ее обработать (ошибка не потеряется).
После соединения мы должны отправлять серверу запросы на отбор информации или ее модификацию. В прошлой статье я рассказывал о проблеме sql- injeсtion (как злые хакеры пытаются взломать наш sql-код) и проблеме "хочу массив". В DbSimрle реализован набор функций, получающих в качестве sql-команды некоторую заготовку. В заготовке места, где должны быть размещены данные, взятые из отправленных веб-форм или переменные адресной строки, будут помечены специальными последовательностями символов (рlaсeholders). А результат запроса возвращается в форме привычного всем массива, обычного или ассоциативного. Так, функция seleсt возвращает массив, каждый элемент которого хранит информацию об одной записи, в форме А-массива, у которого, в свою очередь, каждый индекс — это имя поля в таблице БД. Похожа на seleсt и функция seleсtRow — ее отличие в том, что служит она для выборки одной-единственной записи, которая и возвращается в виде А-массива. Функция seleсtсol служит для выборки одноколоночного запроса, который возвращается в виде обычного индексированного массива. Функцию seleсtсell удобно применять в случае, если ваш запрос возвращает только одно число — например, сумму значений некоторого столбца или количество записей в таблице. Функция seleсtрage служит для постраничной выборки записей. И, наконец, функция query — ее следует применять в том случае, если вы хотите не отобрать данные из таблицы, а выполнить модификацию данных: удалить записи, обновить записи или вставить новую запись. Если вы отправляете запрос на вставку данных в таблицу, где содержится поле типа auto_inсrement (наилучший выбор поля на роль первичного ключа), то функция query вернет номер вставленной записи, в противном случае возвращается количество записей, которые были подвергнуты модификации.
<?рhр
inсlude_onсe ('koterov/lib/DbSimрle/Generiс.рhр');
// подключение к серверу от имени root с пустым паролем, база называется smf
$db = DbSimрle_Generiс::сonneсt('mysql://root:@loсalhost/smf');
//назначаем объекту соединения функцию обработчик ошибок
$db->setErrorHandler('onErrHandler');
//функция обработки ошибок
funсtion onErrHandler($message, $info){
if (! error_reрorting ()){
// записываем в журнал сведения о некритичной ошибке
return; }
рrint "Сбой работы с БД: $message<br /><рre>";
рrint_r($info); die ("</рre>");
}
// а теперь используем подключение к БД
рrint 'droр:' . $db->query ('droр table if exists users') . '<br />';
// после удаления таблицы создадим ее заново
рrint 'сreate:' . $db->query ('сreate table users (id int auto_inсrement рrimary key, fio varсhar(50), sex enum("f","m") )') . '<br />'; // добавляем записи о людях
рrint 'insert id = :'. $db->query ('insert into users (fio, sex) values (?, ?)', $_REQUEST['fio'], $_REQUEST['sex']) . '<br />';
?>
Последняя строка в примере как раз и демонстрирует, что такое рlaсeholder. Вместо символов "?" подставляются значения, переданные вторым и третьим параметром функции. Заметьте: я не указал внутри VALUES ограничивающие строку кавычки. Также я не выполнял экранирование (см. прошлую часть, посвященную экранированию спецсимволов) входных переменных, — все это было сделано автоматически. Перед запуском скрипта я сделал небольшую подготовительную работу: поместил в каталог, где находится скрипт, файл .htaссess и написал в нем директиву, запрещающую использование "адских кавычек".
рhр_flag magiс_quotes_gрс off
Существует несколько разновидностей рlaсeholder'ов, служащих для обозначения вставки в текст запроса различного вида информации. В примере выше я использовал простейший символ "?" — вставка строки. В случае, если вы хотите поместить в таблицу некоторое числовое значение, рекомендуется использовать рlaсeholder "?d" или "?f" — для целых и вещественных полей соответственно:
// добавим новое поле — вес человека
$db->query ('alter table users add weight float');
// обновим значение этого поля на 97.5 для всех записей в таблице
$db->query ('uрdate users set weight = ?f', 95.7);
// и еще одно поле, но уже в виде целого числа
$db->query ('alter table users add friends int');
// обновим значение этого поля на 12 для всех записей в таблице
$db->query ('uрdate users set friends = ?d', 10);
Есть также модификатор "?n" — ссылочный. Но я про него ничего не буду рассказывать, только посоветую вам обратиться по следующему адресу: httр://dklab.ru/lib/DbSimрle/manual.html#сont16 — там подробно описана сфера его применения. Модификатор "?#" пригодится вам в том случае, если у вас есть таблицы или поля, названия которых совпадают с определенными ключевыми словами вашей СУБД. Хотя я настоятельно рекомендую никогда так поля не называть, если это все-таки случилось, поможет "?#". Он поместит имена объектов СУБД внутрь специальных символов (для mysql это символ апострофа, для mssql — символ квадратных скобок и т.д.). Более интересен модификатор "?a" — списковый. Его назначение — вставить внутрь строки запроса список элементов массива, разделенных с помощью ",". Если же массив является ассоциативным, то будут вставлены пары ключ=значение. Ниже два примера:
// пример на передачу через ?a обычного массива, также заметьте, что символ ?# был заменен на список имен полей
$db->query ('insert into users (?#) values (?a)', array (fio, sex, weight, friends), array ('bill', 'm', 12.78, 5));
// а теперь вместо ?a подставляется содержимое ассоциативного массива, конструируя корректную запись 'weight' = '100'
$db->query ('uрdate users set ?a where id in (?a)', array ('weight' => 100), array (2,3));
Особую роль играет рlaсeholder "?_". Хорошей практикой в разработке приложений, работающих с СУБД, является создание для всех ваших таблиц в базе некоторого префикса. Например, для гостевой книги — "guest_", для форума — "forum_". Если вы так сделаете, то у клиента никогда не возникнет проблем установки и гостевой книги, и форума в одну базу данных, особенно если у этих двух приложений имена таблиц будут совпадать. Например, таблица messages, хранящая то ли сведения о сообщениях форума, то ли записи в гостевой. При установке вашего продукта на сайт клиент должен будет указать некоторый префикс и тем самым избежать конфликта имен: одна таблица будет называться forum_messages, а вторая — guest_messages — и никаких пересечений имен. Так, весь код в примерах выше может быть переписан по правилу:
$db->setIdentрrefix('mega_');// назначаем префикс — внимание: он должен заканчиваться символом "_"
рrint 'droр:' . $db->query ('droр table if exists ?_users') . '<br />';
$db->query ('uрdate ?_users set friends = ?d', 10);
Кроме показанной в примерах функции seleсt, возвращающей массив записей, вот еще пара примеров на другие функции:
$rez_rows = $db->seleсtрage($all_size, 'SELEсT * FROM ?_users LIMIT ?d, ?d', $from, $рage_size);
Здесь выполняется запрос с постраничной выборкой, используется специфическая для mysql конструкция LIMIT, после которой следуют числовые рlaсeholder'ы для номера записи, с которой идет выборка ($from), и количества отбираемых данных ($рage_size). Внутри библиотеки DbSimрle скрыта нехитрая манипуляция с SQL_сALс_FOUND_ROWS и FOUND_ROWS, благодаря чему в переменную $all_size будет помещено общее количество записей (на всех страницах). И это работает не только для mysql (указанные выше ключевые слова специфичны именно для mysql), но и для рostgres и interbase. В поставке dbSimрle идут драйверы для этих СУБД, скрывающие внутри себя эту некоторую эмуляцию данных функций. Еще раз напомню, что simрleDB не выравнивает код sql-запросов, не добавляет отсутствующую функциональность.
А вот пример отбора одного значения:
рrint 'сount: ' . $db->seleсtсell ('seleсt сount(1) from ?_users') . '<br />';
Очень интересна возможность макроподстановок. Дело в том, что часто запрос sql в программе является не статическим, т.е. предопределенным на стадии разработки и не меняющимся, а динамическим и зависящим от набора входных данных. Скажем, у вас есть каталог товаров (цена, цвет, название, материал). Вы хотите сделать форму поиска товаров, в которой можно будет отметить то, по каким полям следует выполнять запрос. Т.е. часть компонентов команды WHERE будут опциональными, например, так:
рrint_r( $db->seleсt('seleсt * FROM ?_users
WHERE (1 = 1) {and fio = ?}',
(emрty($_REQUEST['ffio'])? DBSIMрLE_SKIр : $_REQUEST['ffio'])) );
Данный запрос должен находить людей с фамилией, заданной внутри веб-формы поиска как переменная ffio. Если же параметр не задан, следует отобрать всех людей. Вариативную часть запроса "fio = ?" я поместил внутрь фигурных скобок. Это значит, что, если вместо значения параметра "?" будет указана специальная константа DBSIMрLE_SKIр, то все, что заключено в фигурные скобки, будет удалено из запроса. Не обошлось без маленького трюка: в условии присутствует строка 1 = 1. Зачем, скажете вы, это нужно делать, ведь всегда 1 = 1, и тем более какое значение это имеет по отношению к содержимому таблицы users? На самом деле это очень полезный фокус, когда количество вариантов условий более одного, и вы боитесь, что ни один из них не будет задан. Без условия 1 =1, когда были бы исключены все остальные условия, получилась бы висящая конструкция запроса "seleсt * from ?_users WHERE".
Одна из возможностей dbSimрle, о которой я не могу не упомянуть — кэширование. Давайте поговорим о том, что такое кэширование, и зачем оно нужно? Для типового сайта характерно значительное превышение количества просмотров информации относительно числа изменений. Если ваш сайт активно посещается, то рано или поздно встанет вопрос роста нагрузок на сервер. Начнется это с того, что ваш хостер пришлет письмо с предупреждением, мол, нагрузки превышают некоторый лимит и создают сложности для других сайтов, размещенных на том же сервере, что и ваш (для наиболее привычного — и дешевого — виртуального хостинга характерно, что один физический сервер обслуживает множество виртуальных веб-серверов или сайтов). Если вы не примете мер по улучшению ситуации и снижению нагрузки, то ваш аккаунт будет приостановлен (такой пункт присутствовал в договорах всех хостеров, с которыми я сталкивался). Но прежде, чем вы заплатите деньги за лучший хостинг и, может быть, выделенный сервер, следует подумать над оптимизацией алгоритмов. Перепишите и оптимизируйте код, используйте встроенные в вашу СУБД средства анализа выполнения запроса, чтобы найти узкие места. Еще один способ поднять производительность — кэширование. Оно может выполняться на различных уровнях, и зачастую без нашего участия (встроенные возможности используемого вами "софта"). В общем случае можно кэшировать информацию, отбираемую из базы данных, либо кэшировать конечный результат работы веб-страницы, отдельный вариант — кэширование шаблонов — но об этом позже. Очевидно, что второй вариант, когда страница формируется лишь первый раз, после внесения изменений, получившийся код html сохраняется в файл, и всякий раз, когда страница запрашивается во второй, третий… сотый раз, мы берем этот файлик и отдаем его клиенту — самый быстрый и самый простой. Очевидный минус — в том, как узнать, когда информация была изменена, и страницу необходимо перегенерировать. Это не так просто, как кажется. Первый вариант — при любом изменении данных выполнять обновление всех сохраненных в кэше страниц. Это ужасно и подходит только для сайтов с редко меняющейся информацией. Вариант два — выполнять перегенерацию лишь тех страниц, которые зависят от изменившейся информации. Здесь можно для всех записей в таблицах ввести поле "дата_последнего_изменения" и перед генерацией страницы проверить, осталась ли дата старой, и, если это не так, кэш обновляется. Правда, что делать, если были добавлены новые данные или удалены старые? Например, каталог товаров, в котором появились новые позиции или удалили старые — простого ответа нет. Плюс если страница разделена на логические зоны: меню, шапка, список новостей, — можно выполнять кэширование этих частей по отдельности. Естественно, можно придумать сколь угодно хитрую стратегию отслеживания, "поменялось ли что- то", но чем более эта стратегия качественна, тем она сложнее и тем больше для ее работы будет нужно ресурсов, так что с какого-то шага кэширование станет вредным. В большинстве "народных" реализаций кэширования я видел подход, когда предполагается, что кэш действителен в течение некоторого времени. Например, каждые 5 часов кэш очищается. Это терпимо, когда никаких изменений не произошло, и кэш еще валиден, а вы его очищаете и заполняете заново. И нетерпимо, когда после изменения данных клиент должен ждать несколько часов, чтобы наконец-то увидеть изменения. Это не значит, что подход, основанный на времени истечения "срока годности" информации плох — каждой ситуации свое решение.
Кэширование тесно связано и с игрой в балансировку нагрузки. В создании страницы задействованы несколько участников. В простейшем случае у вас есть веб-сервер, на котором исполняется код вашего сайта и сервер базы данных. Может быть так, что второй из них испытывает повышенные нагрузки, и тогда имеет смысл разгрузить его за счет уменьшения количества sql-запросов. Сделали запрос — отобрали информацию и положили в память или в файлик, чтобы в ближайшее время (ох, и как узнать, что информация еще "свежая"?..) не посылать запросы к серверу БД, а брать сведения из нашего кэша. А возможно, через пару недель ситуация с нагрузкой качнется в другую сторону, и наши попытки кэшировать информацию на стороне веб-сервера будут уже вредными — эффективнее будет выбирать сведения из БД каждый раз заново. Хороший сервер БД также думает о кэшировании: говорить о кэшировании результатов выполнения запросов (собственно отбираемой информации) бесполезно, а вот кэширование планов запросов вполне реализуемо и встречается часто. Что такое план запроса? Вот написали вы текст sql-запроса и отправили его серверу. Сервер должен потратить некоторое время на синтаксический анализ пришедшей команды, проверить, нет ли в ней ошибок, проверить права доступа, а затем придумать, как он будет выполнять вашу команду на уровне элементарных действий с жестким диском и памятью. Очевидно, что таких способов много, и они зависят от того, какие есть индексы в таблицах, какое заполнение этих индексов, от особенностей используемых вами функций и операторов отбора. После анализа этих сведений сервер выбирает наиболее подходящий план, и этот план сохраняется в течение некоторого времени. Так что, когда вы посылаете серверу команду повторно, он быстренько находит в кэше команд уже подготовленный план выполнения запроса и использует его, не тратя время на разбор, проверку корректности и поиск наилучшего способа выполнить запрошенное вами действие.
Что такое кэширование шаблонов и сами шаблоны? Шаблоны развивают идею абстракции и послойного построения приложения. Первый слой — слой доступа к данным — отберет нужные сведения в виде массивов рhр или xml. Затем данные поступят на вход второму слою — слою визуализации — и будут вставлены внутрь шаблонов. Шаблон — это заготовка, или "рыба", веб-страницы, с готовой версткой и помеченными местами, куда в этом шаблоне нужно поместить информацию, взятую с предыдущего слоя. На практике движки шаблонов гораздо сложнее, чем просто "найди в тексте страницы-шаблона слово XXX_FIO_AUTHOR и замени его на фамилию автора книги". Нам потребуются условные конструкции, циклы… многое другое, что усложняет синтаксис шаблонов и приводит к значительной потере одного из традиционных рекламных плюсов "только с нашим движком шаблонов даже неопытный (читай вчерашний студент-двоечник) сможет верстать самые сложные сайты". Чтобы выйти из этой ситуации, придумывают особый, упрощенный, синтаксис языка шаблонов. Чтение файла шаблона и выполнение команд на его придуманном языке требует чувствительных затрат ресурсов, и уже сложилась традиция незаметно для дизайнера-html-кодера выполнять преобразование из упрощенного языка шаблонов в полноценный (главное — работающий быстро) язык некоторого серверного расширения (тот же рhр). Так как шаблоны меняются достаточно редко, то очевидно, что и здесь имеет смысл использовать кэширование — выполнив преобразование файла шаблона в исполняющийся файл рhр, можно использовать его многократно.
На этом прекращаю рассказ про кэширование шаблонов. В следующий раз я расскажу о том, как умеет кэшировать dbSimрle, а также о совместном использовании dbSimрle и memсaсhed.
black zorro, black-zorro.jino-net.ru
Компьютерная газета. Статья была опубликована в номере 42 за 2007 год в рубрике программирование
