Webew.ru: теория и практика веб-технологий

Псевдо-checkbox на чистом CSS без фоновых изображений

Sat, 24 Jun 2017 16:41:54 +0300

Как сделать красивый стилизованный чекбокс и при этом не написать ни строчки javascript и не искать иконки.

это обычный чекбокс а это - стилизованный

Вот как выглядит код стилизованного чекбокса:

<label>

    <input type="checkbox">

    <span class="pseudocheckbox">а это - стилизованный</span>

</label>

input[type=checkbox] { display: none; }

.pseudocheckbox::before {   

    content: "\00A0";

    display: inline-block;

    box-sizing: border-box;

    width: 20px; 

    height: 20px;

    background-color: white;

    border: 2px solid #B0B0B0;

    border-radius: 2px;

    margin-right: 6px;

    vertical-align: baseline;

    text-align: center;

    font-family: Arial, sans-serif;

    font-size: 16px;

    line-height: 16px;

    font-weight: bold;

    color: #808080;

}

input[type=checkbox]:checked + .pseudocheckbox::before { content: "\2713"; }

Разберем этот код подробно.

Задействуем <label>

Для начала нужно скрыть сам чекбокс:

input[type=checkbox] { display: none; }

Его и относящийся к нему текст нужно заключить в label, чтобы клик мыши по тексту приводил к изменению состояния чекбокса:

<label>

    <input type="checkbox">

    <span class="pseudocheckbox">а это - стилизованный</span>

</label>

Мы, однако, не только поместили текст внутрь <label>, но и обернули его в <span>. Для чего же это нужно?

Селектор соседа и псевдокласс :checked

В CSS есть селектор соседа. Он позволяет применить стили к указанному элементу только в том случае, если прямо перед ним есть некоторый другой элемент. Записывается он с помощью символа + и выглядит, например, вот так:

input[type=checkbox] + span { (правила) }

Вышеуказанная запись означает: применить правила ко всем <span>, перед которыми есть <input type="checkbox">.

С помощью подобного выражения можно провернуть одну хитрость: ограничить предшествующие элементы только теми чекбоксами, которые «включены». Это нам позволит сделать псевдокласс :checked:

input[type=checkbox]:checked + span { (правила) }

Такая запись позволяет визуально выделить конкретно те <span>, которые следуют за включенными чекбоксами. Эффект от такого выделения иллюстрирует простейший пример:

<label>

    <input type="checkbox">

    <span>щелкни по мне</span>

</label>

input[type=checkbox]:checked + span { font-weight: bold; }

Вот как получится:

щелкни по мне

(Заметим, что <span> вместе с <input type=checkbox> находится внутри <label>, поэтому клик по нему приводит к изменению состояния <input>.)

Селектор в исходном примере выглядит немного по-другому: не
input[type=checkbox]:checked + span, а
input[type=checkbox]:checked + .pseudocheckbox. По такому селектору браузер быстрее найдет нужный элемент: ему легче искать среди элементов класса pseudocheckbox, чем среди всех <span>. Так что класс добавлен для повышения производительности и никакой другой смысловой нагрузки не несет.

Стилизуем ::before

Вернемся к нашей задаче. Нам требуется не выделять сам <span>, а добиться, чтобы слева от него появилось нечто похожее на переключатель. Для этого нам поможет псевдоэлемент ::before.

::before — это способ дописать что-то в элемент непосредственно перед его содержимым средствами CSS.

<div>раз</div>

<div>два</div>

div::before { content: "Это ::before "; }

раз

два

Современные браузеры позволяют стилизовать ::before так же, как это делается для обычных HTML-элементов: задавать размеры и отступы, добавлять границы, фон и т.д. Это позволит нам придать ему вид квадратика с рамкой, похожего на переключатель. Взглянем еще раз на правила для него и разберемся, для чего нужно каждое из них:

.pseudocheckbox::before {  

    content: "\00A0";

    display: inline-block;

    box-sizing: border-box;

    width: 20px; 

    height: 20px;

    background-color: white;

    border: 2px solid #B0B0B0;

    border-radius: 2px;

    margin-right: 6px;

    vertical-align: baseline;

    text-align: center;

    font-family: Arial, sans-serif;

    font-size: 16px;

    line-height: 16px;

    font-weight: bold;

    color: #808080;

}

content — свойство, необходимое псевдоэлементу, чтобы он проявился. Достаточно даже пустой строки. Но мы используем неразрывный пробел (об этом будет рассказано ниже). Его шестнадцатеричный код — 00A0:

content: "\00A0";

Нужно задать нашему «квадратику» ширину и высоту. Чтобы они подействовали, необходимо также указать display: inline-block; (по умолчанию у ::before — inline):

display: inline-block;

width: 20px;

height: 20px;

Удобней, чтобы ширина и высота рассчитывались с учетом толщины границ:

box-sizing: border-box;

Которые тут же и укажем вместе с закруглениями для красоты:

border: 2px solid #B0B0B0;

border-radius: 2px;

И добавим небольшой отступ от текста:

margin-right: 6px;

Следует также обратить внимание на выравнивание самого «квадратика» относительно соседнего текста. Одним из подходящих вариантов является выравнивание по базовой линии текста:

vertical-align: baseline;

В случае самого «квадратика» текстом является неразрывный пробел. Если бы текста внутри не было (content: ""), такое выравнивание не подействовало бы. Вот почему в content именно неразрывный пробел, а не пустая строка: выглядят они одинаково, а действуют в данном случае по-разному.

Остальные свойства относятся к переключателю в состоянии «включено».

Состояние «включено» и Unicode-символ «галочка»

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

input[type=checkbox]:checked + .pseudocheckbox::before { ... }

Отмеченный переключатель обычно имеет внутри «галочку». Здесь нам на помощь приходит разнообразие символов Unicode, которое выходят далеко за пределы собственно букв и цифр. Есть среди этого многообразия и несколько значков для «галочки». Код значка мы запишем в свойство content:

input[type=checkbox]:checked + .pseudocheckbox::before { content: "\2714"; }

В результате «галочка» будет вписана во все «квадратики» рядом с отмеченными чекбоксами, чего мы и добивалсь. Однако, не стоит забывать, что технически такая «галочка» — это обычный текстовый символ, который самостоятельно может и не выглядеть ровно так, как надо, и ему нужно ему в этом немного помочь.

Центрируем по горизонтали:

text-align: center;

В разных шрифтах символ «галочки» может выглядеть немного по-разному, поэтому для ясности выбираем какой-то один и указываем его явно. Также подбираем размер:

    font-family: Arial, sans-serif;

font-size: 16px;

Кроме размера нужно добиться необходимого положения символа внутри квадратика по вертикальной оси. Лучше всего это делать с помощью line-height:

line-height: 16px;

line-height нужно подбирать индивидуально для каждого сочетания размера и семейства шрифта.

При выравнивании по базовой линии текста (vertical-align: baseline) именно значение line-height определеяет, где, собственно, будет нижняя граница текста у «квадратика». Если эти значения у отмеченного и неотмеченного будут отличаться, то они окажутся выровненными по-разному (так может получиться, например, если явно указать line-height только у отмеченного). Поэтому line-height лучше указывать в общем блоке стилей для ::before.

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

Напоследок добавим жирность и укажем цвет:

font-weight: bold;

color: #808080;

Средства навигации по сайту: генерация с помощью PHP

Fri, 25 Dec 2015 15:31:19 +0300

Вниманию читателей предлагается небольшая библиотека функций для языка PHP, предназначенная, в основном, для создания интерфейсов навигации по спискам. Библиотека позволяет сделать необходимый PHP-код очень компактным.

Замена значений GET-параметров в адресах

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

Распространенный пример — номер страницы списка:

# Предположим, URL текущей страницы - http://site.ru/catalogue/?a=100&b=200&N=50

# Пусть за номер страницы отвечает параметр 'p'.

# Тогда чтобы получить URL для страницы № 2, нужен вот такой код:

$url = substitute_url_get_parameter('p', 2);

# Функция вернет адрес, начиная со слэша (без доменного имени):

# /catalogue/?a=100&b=200&N=50&p=2

Если в качестве значения GET-параметра функции передать NULL, то он будет полностью исключен из адреса:

# Предположим, мы на странице /catalogue/?a=100&b=200&N=50&p=2

$url = substitute_url_get_parameter('p', '');   // вернет /catalogue/?a=100&b=200&N=50&p

$url = substitute_url_get_parameter('p', NULL); // вернет /catalogue/?a=100&b=200&N=50

Если в адресе нужно заменить сразу несколько параметров, это можно сделать за один вызов функции:

 # Для страницы /catalogue/?a=100&b=200&N=50&p=2&x=1

$url = substitute_url_get_parameter( [ 'N' => 100, 'p' => NULL ] ); 

# даст /catalogue/?a=100&b=200&N=100&x=1

# Можно указывать единое значение для всех параметров (это удобно, если их нужно удалить)

$url = substitute_url_get_parameter(['N', 'p'], '');   # даст /catalogue/?a=100&b=200&N&p&x=1

$url = substitute_url_get_parameter(['N', 'p'], NULL); # даст /catalogue/?a=100&b=200&x=1

По умолчанию функция использует адрес текущей страницы ($_SERVER['REQUEST_URI']). Если нужно использовать какой-то другой, его следует передать в качестве третьего аргумента:

$url = substitute_url_get_parameter('p', 2, $some_url);

# Вызов вида substitute_url_get_parameter('p', 2)

# равносилен substitute_url_get_parameter('p', 2, $_SERVER['REQUEST_URI'])

Есть специальный режим работы функции, который позволяет удалить из адреса все GET-параметры, кроме указанных, которым, при желании, установить другие значения или же оставить их в неизменном виде:

$url = substitute_url_get_parameter( ['-', 'N', 'x'=>3] );

# Для страницы http://site.ru/catalogue/?a=100&b=200&N=50&x=1

#         даст http://site.ru/catalogue/?N=50&x=3

Как видно из примера, для работы в этом режиме первым аргументом функции нужно передать массив, первым элементом которого является строка '-', а последующими — те переменные, которые следует оставить в адресе.

Соответственно, вызов вида substitute_url_get_parameter( ['-'] ) позволяет получить адрес без GET-параметров.

Разбиение списка на страницы

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

Для решения такой задачи служит функция nav_pages():

$pages = nav_pages(

    'p', // номер страницы - в $_GET[p]

    20,  // сколько записей на одной странице  

    $total_rows // суммарное число записей в разбиваемом на странице списке

);

В случае текущего адреса /catalogue/?a=100&b=200&p=3 результат работы функции будет таким:

Ссылки prev и next присутствуют, если текущей не является первая или последняя страница соответственно. Ссылки first и last присутствуют в случае, если первая или последняя страница не попали в общий список из-за ограничения на его длину¹. Это ограничение можно установить, передав функции дополнительный аргумент:

$pages = nav_pages(

    'p',

    20,  

    $total_rows,

    10 // перечень страниц должен состоять не более чем из 10-ти ссылок (не считая special)

);

Число записей на одной странице может, в свою очередь, регулироваться GET-параметром — можно указать функции использовать этот параметр и установить значение по умолчанию на случай, если он не задан:

$pages = nav_pages(

    'p',

    ['N', 20],   // число записей забираем из $_GET[N]  

    $total_rows, // если же $_GET[N] пуст или вовсе не задан — выводим по 20 штук

    10

);

Наконец, последним аргументом можно передать адрес, отличный от $_SERVER['REQUEST_URI'].

В меню навигации ссылку, соответствующую текущей странице, логично визуально выделить и при этом убрать у неё атрибут href²:

HTML-код такого меню можно получить из следующего шаблона (здесь и далее приводятся примеры для шаблонизатора websun):

<nav>

    Страницы: 

    {?*special.first*} <a href="{*special.first.url*}">в начало</a> {?}

    {?*special.prev*} <a href="{*special.prev.url*}">предыдущая</a> {?}

    {%*list*}

        <a {?!*list:current*} href="{*list:url*}" {?} >{*list:num*}</a>

    {%}

    {?*special.next*} <a href="{*special.next.url*}">следующая</a> {?}

    {?*special.last*} <a href="{*special.last.url*}">в конец</a> {?}

</nav>

<style>

    /* для текущей страницы и остальных устанавливаем разные стили; отличаем их по наличию атрибута href */

    nav a[href] { font-weight: normal; }

    nav a:not([href]) { font-weight: bold; }

</style>

Вместо номеров страниц можно указывать диапазон порядковых номеров самих записей:

В шаблоне для этого используются ключи min и max:

<nav>

    ...

    {%*list*}

        <a ...>{*list:min*}–{*list:max*}</a>

    {*list*%}

    ...

</nav>

Меню переключателей на основе GET-параметра

Встречаются ситуации, в которых нужно построить навигационное меню из однотипных ссылок, адреса которых отличаются только значением одного из GET-параметров³. При этом пункт меню, соответствующий текущей странице, должен визуально отличаться от остальных.

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

Вид: построчно сетка плашки

Для построения такого меню используется функция nav_switches(), которой требуется передать имя GET-параметра и перечень пунктов меню, каждый из которых определяется текстом ссылки и значением параметра⁴:

$cfg = [

    '' => 'построчно', // элемент с пустым ключом - по умолчанию

    'grid' => 'сетка',

    'plates' => 'плашки'

];

$menu = nav_switches('view', $cfg);

Например, для третьей страницы списка, представленного в виде сетки — адрес /catalogue/?p=3&view=grid — содержимое $menu таково:

Array

(

    [0] => Array

        (

            [value] => 

            [text] => построчно

            [current] => 

            [url] => /catalogue/?p=3

        )

    [1] => Array

        (

            [value] => grid

            [text] => сетка

            [current] => 1

            [url] => /catalogue/?p=3&view=grid

        )

    [2] => Array

        (

            [value] => plates

            [text] => плашки

            [current] => 

            [url] => /catalogue/?p=3&view=plates

        )

)

Следует отметить, что все GET-параметры, кроме view, сохраняют свои значения в адресах ссылок меню. При этом в ссылке на вид построчно view отсутствует, поскольку этот вид выбран в качестве представления списка по умолчанию.

HTML-шаблон меню выглядит примерно так:

<menu>

{%**}<a {?!*:current*} href="{*:url*}" {*:current*?!}>{*:text*}</a>{**%}

</menu>

Другой пример переключения на основе GET-параметра — регулировка количества записей на странице.

// выводить по 10,20,50 и 100; по умолчанию - 20 

$cfg = [ 10, '' => 20, 50, 100 ];

Здесь значение параметра — количество записей — служит сразу же и текстом ссылки (за исключением случая по умолчанию, когда значением является пустая строка).

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

$menu = nav_switches('N', $cfg, 'p');

Для страницы /catalogue/?p=3 $menu выглядит так:

Array

(

    [0] => Array

        (

            [value] => 10

            [text] => 10

            [current] => 

            [url] => /catalogue/?N=10

        )

    [1] => Array

        (

            [value] => 

            [text] => 20

            [current] => 1

            [url] => /catalogue/

        )

    [2] => Array

        (

            [value] => 50

            [text] => 50

            [current] => 

            [url] => /catalogue/?N=50

        )

    [3] => Array

        (

            [value] => 100

            [text] => 100

            [current] => 

            [url] => /catalogue/?N=100

        )

)

Последним аргументом можно передать адрес страницы, для которой строится меню, если это не $_SERVER['REQUEST_URI'].

Переключение режимов сортировки

Режим сортировки определяется не только параметром, по которому она осуществляется, но также и направлением (возрастание или убывание).

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

...&sort=price — сортировка по возрастанию цены
...&sort=price+DESC⁵ — сортировка по убыванию цены

Обычно в меню сортировки каждому параметру соответствует по одной ссылке; та, что относится к выбранному в данный момент, выделяется визуально и при этом остается кликабельной, указывая на сортировку с противоположным направлением (это видно, если навести на нее указатель мыши). Например:

Сортировка: по цене по названию по дате

Для генерации данных подобного меню служит функция nav_sort(), вызов которой в данном случае будет выглядеть следующим образом:

$cfg = [

    'price' => 'по цене DESC', 

    'name' => 'по названию',

    'date' => 'по дате DESC',

];

$menu = nav_sort('sort', $cfg, 'p');

// Третий аргумент — 'p' — указывает на имя GET-переменной, 

// содержащей номер страницы, и необходим для того,

// чтобы каждая ссылка всегда указывала на первую страницу списка.

Содержимое $menu для страницы /catalogue/ выглядит так:

Array

(

    [0] => Array

        (

            [is_current] => 1

            [direction] => DESC

            [url] => /t-ajax.php?sort=price

            [text] => по цене

        )

    [1] => Array

        (

            [is_current] => 

            [direction] => ASC

            [url] => /t-ajax.php?sort=name

            [text] => по названию

        )

    [2] => Array

        (

            [is_current] => 

            [direction] => DESC

            [url] => /t-ajax.php?sort=date+DESC

            [text] => по дате

        )

)

HTML-шаблон меню выглядит примерно так:

<menu>

{%**}

    <a 

     class="{?*:current*}current{*:current*?} {*:direction*}"

     href="{*:url*}"

    >{*:text*}</a>

{**%}

</menu>

Каждая из ссылок в таком случае будет иметь класс ASC или DESC, а соответствующая текущему режиму сортировки — еще и класс current. Это позволит эффективно управлять их внешним видом с помощью CSS:

/* Текущий режим сортировки выделяем жирным. */

a.current { font-weight: bold; }

/* В зависимости от направления дописываем к тексту ссылки фрагмент "(возр.|убыв.)". */

a.ASC:after { content: " (возр.)"; }

a.DESC:after { content: " (убыв.)"; }

/* У выделенных ссылок ситуация сложнее:

при наведении мыши они должны показывать то направление, 

которое станет действовать, если на ссылку нажать,

то есть обратное текущему. */

a.current.ASC:hover:after { content: " (убыв.)"; }

a.current.DESC:hover:after { content: " (возр.)"; }

В другом варианте организации меню отдельная ссылка соответствует каждому варианту направления сортировки, получается по две ссылки на каждый параметр:

по возрастанию цены по убыванию цены по дате, сначала старые по дате, сначала новые

Этому варианту соответствует такая конфигурация:

$cfg = [

    'price' => 'по {возрастанию|убыванию} цены DESC',

    'date' => 'по дате, сначала {старые|новые}'

];

Кроме того, понадобится немного другой шаблон:

<menu>

    {%**}

        <a 

         {?*:current*} class="current" {*:current*?}

         {?*:url*} href="{*:url*}" {*:url*?}

        >{*:text*}</a>

    {**%}

</menu>

Последним аргументом функции можно передать адрес страницы, если это не $_SERVER['REQUEST_URI'].

1. ▲ Если до последней страницы «еще далеко» (две или более от крайней в обычном списке), среди special появляется также ссылка forward. Удобна для случаев, когда нужно показать номер последней страницы (чтобы дать пользователю представление о том, сколько всего страниц) и отделить его от остальных, например, многоточием:

forward соответствует странице, следующей за последней из основного списка.

Если «уже далеко» до первой страницы - в special появляется ссылка backward; соответствует странице, предшествующей самой первой из основного списка.

2. ▲ Отстутствие href сделает ссылку некликабельной.

3. ▲ Представление по умолчанию включается в случае отсутствия в адресе страницы GET-параметра, регулирующего представление.

4. ▲ Есть также полная форма записи, в двух вариантах:

// первый вариант

$cfg = [

    [ '', 'построчно' ],

    [ 'grid', 'сетка' ],

    [ 'plates', 'плашки' ]

];

// второй вариант

$cfg = [

    [ 'value' => '', 'title' => 'построчно' ],

    [ 'value' => 'grid', 'title' => 'сетка' ],

    [ 'value' => 'plates', 'title' => 'плашки' ]

];

Полную форму необходимо использовать, если значениями являются целые числа и при этом в качестве текстов используются не значения, а что-то другое. Например:

$cfg = [

    [ 1, 1000 ],

    [ 2, 2000 ],

    [ 3, 3000 ],

    [ 5, 'пять тысяч' ],

    [ 7, 'семь тысяч' ],

    [ 10, 'десять тысяч' ],

    [ 'value' => 20, 'title' => 'двадцать тысяч' ],

    [ 'value' => 30, 'title' => 'тридцать тысяч' ],

    [ 'value' => 40, 'title' => 40000 ],

    [ 'value' => 50, 'title' => 50000 ],

];

5. ▲ + — это URL-закодированный пробел. ASC — по возрастанию (от ascendant), DESC — по убыванию (от descendant), по аналогии с синтаксисом языка SQL.

Простая функция для измерений скорости и использования памяти в PHP

Tue, 15 Dec 2015 22:13:43 +0300

Вниманию читателей предлагается простой программный интерфейс для сбора значений microtime() и memory_get_usage() и представления их в удобном для восприятия виде.

Пользоваться функцией очень легко. Нужно вызвать её в самом начале скритпа, а затем — после каждой интересующей операции, передав в качестве аргумента массив для записи и имя для конкретного измеряемого отрезка:

require_once 'benchmark.function.php';

benchmark($BENCHMARK, 'start'); // запускаем измерение 

$N = 1000000;

for ($i = 0; $i < $N; $i++) ; // пустой цикл

benchmark($BENCHMARK, 'i');

for ($j = 0; $j < 2*$N; $j++) ;

benchmark($BENCHMARK, 'j');

for ($h = 0; $h < 3*$N; $h++) ;

benchmark($BENCHMARK, 'h');

Содержимое $BENCHMARK будет примерно следующим:

Array

(

    [recent] => Array

        (

            [time] => 1450175830.0469

            [memory] => 973360

            [memory_peak] => 980464

        )

    [total] => Array

        (

            [time] => 376

            [memory] => 0.93

            [memory_peak] => 0.94

        )

    [list] => Array

        (

            [start] => Array

                (

                    [time] => 0

                    [memory] => 0.93

                    [memory_peak] => 0.94

                )

            [i] => Array

                (

                    [time] => 63

                    [memory] => 0

                    [memory_peak] => 0

                )

            [j] => Array

                (

                    [time] => 141

                    [memory] => 0

                    [memory_peak] => 0

                )

            [h] => Array

                (

                    [time] => 188

                    [memory] => 0

                    [memory_peak] => 0

                )

        )

)

total — суммарные значения времени выполнения (в миллисекундах) и объема используемой памяти (в мегабайтах) от первого вызова функции до последнего. В list содержатся значения по конкретным отрезкам.

Именовать первый отрезок (в примере выше — start) не обязательно; он будет содержать нулевое время, т.к. это первый вызов. Однако start покажет затраты памяти на холостой запуск PHP-сценария¹.

Повторное указание одного и того же имени отрезка приводит к суммированию значений:

for ($i = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle');

for ($j = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle');

for ($h = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle');

Cycle будет содержать сумму показателей для i, j и h.

Измеряемый отрезок может быть прерывистым. Тогда каждую его часть нужно окружить вызовами benchmark()²:

benchmark($BENCHMARK);

for ($i = 0; $i < $N; $i++) ;

benchmark($BENCHMARK, 'Cycle');

// ...

// Здесь некий код, быстродействие которого отдельно не измеряем.

// Его измерения, однако, войдут в суммарные показатели.

// ...

benchmark($BENCHMARK);

for ($h = 0; $h < 3*$N; $h++) ;

benchmark($BENCHMARK, 'Cycle');

Cycle на этот раз будет содержать сумму показателей для i и h, а total — по-прежнему измерения от первого до последнего вызова benchmark().

Для отрезка можно указывать поясняющий текст, который войдет в состав массива с измерениями в качестве элемента title³:

for ($i = 0; ... ) ...

benchmark($BENCHMARK, 'i:1M');

for ($j = 0; ... ) ...

benchmark($BENCHMARK, 'j:2M');

for ($h = 0; ... ) ...

benchmark($BENCHMARK, 'h:3M');

Array

(

    ...

    [list] => Array

        (

            [i] => Array

                (

                    [time] => 47

                    [memory] => 0

                    [memory_peak] => 0

                    [title] => 1M

                )

            [j] => Array

                (

                    ...

                    [title] => 2M

                )

            [h] => Array

                (

                    ...

                    [title] => 3M

                )

        )

)

Внутри отрезка можно выделять дочерние, измерения по каждому из которых будут проводиться отдельно и суммироваться с измерениями основного⁴. Имена дочерних отрезков отделяются от основного точкой, вложенность не ограничена:

for ($i = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle.i'); 

for ($j = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle.j');

for ($h = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle.h:3M');

Array

(

    [recent] => ...

    [total] => Array

        (

            [time] => 376

            [memory] => 0.93

            [memory_peak] => 0.94

        )

    [list] => Array

        (

            [start] => Array

                (

                    [time] => 0

                    [memory] => 0.93

                    [memory_peak] => 0.94

                )

            [Cycle] => Array

                (

                    [time] => 376

                    [memory] => 0

                    [memory_peak] => 0

                    [list] => Array

                        (

                            [i] => Array

                                (

                                    [time] => 47

                                    [memory] => 0

                                    [memory_peak] => 0

                                )

                            [j] => Array

                                (

                                    [time] => 141

                                    [memory] => 0

                                    [memory_peak] => 0

                                )

                            [h] => Array

                                (

                                    [time] => 188

                                    [memory] => 0

                                    [memory_peak] => 0

                                    [title] => 3M

                                )

                        )

                )

        )

)

Дочерним отрезкам вместо явного определения имен можно указать автоматическую нумерацию:

// Используется специальная конструкция "%+"

for ($i = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle.%+'); 

for ($j = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle.%+');

for ($h = 0; ... ) ...

benchmark($BENCHMARK, 'Cycle.%+:Цикл № %+'); // и в title - тоже

Array

(

    ...

    [list] => Array

        (

            [start] => ...

            [Cycle] => Array

                (

                    ...

                    [list] => Array

                        (

                            [0] => Array

                                (

                                    [time] => 63

                                    [memory] => 0

                                    [memory_peak] => 0

                                )

                            [1] => Array

                                (

                                    [time] => 125

                                    [memory] => 0

                                    [memory_peak] => 0

                                )

                            [2] => Array

                                (

                                    [time] => 188

                                    [memory] => 0

                                    [memory_peak] => 0

                                    [title] => Цикл № 2

                                )

                        )

                )

        )

)

1.▲ За вычетом затрат на подключение benchmark-функции (которые, впрочем, несущественны).

2.▲ Вызов без указания имени отрезка сбрасывает внутренние значения счетчиков и обновляет суммарные показатели.

3.▲ Если отрезок прерывистый, используется вариант поясняющего текста, указанный последним.

4.▲ Можно сказать, что все поименованные отрезки являются дочерними по отношению к total.

Согласованный AJAX-слой для веб-сайта

Tue, 30 Dec 2014 10:26:21 +0300

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

Чтобы реализовать на сайте согласованный AJAX-слой, нужно:

составить список взаимно согласованных блоков
подключить небольшую javascript-библиотеку и установить на сайт специальный код¹
подготовить серверную часть для AJAX-ответа

Ярким примером сайта, которому необходим согласованный AJAX-слой, является интернет-магазин. Для него мы и рассмотрим технику внедрения.

Определение состава AJAX-слоя

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

Типичный интернет-магазин имеет практически на всех страницах:

Блок с общей информацией о содержимом корзины — назовем его cart:brief.
Этот блок должен обновляться при изменении состава покупок: нажатии кнопки «купить», авторизации пользователя, у которого была непустая корзина и т.д.
Зону авторизации: форма, кнопка «войти» и пр., или же, для авторизованных пользователей, некую личную информацию (приветствие и пр.) — auth:brief.
Обновление требуется при успешной авторизации или регистрации пользователя.
Список товарных предложений, каждое из которых снабжено кнопкой «купить» или надписью «товар в корзине». Участником слоя в данном случае является контейнер кнопки, ему дадим имя вида buy:{id товара} (имя тогда будет уникальным, даже если на странице присутствует несколько товаров).
Наличие кнопки должно согласовываться с присутствием товара в корзине и обновляться при изменении списка покупок.

Приписание блокам их имен осуществляется посредством установки значения атрибуту data-*. Конкретное имя атрибута можно выбирать произвольно, главное, чтобы у всех элементов оно было одинаковым².

В случае примера можно сказать, что мы имеем дело с неким персональным слоем покупателя, поэтому назвать атрибут можно, например, data-personal-ajax. В HTML-код перечисленных выше блоков тогда нужно добавить атрибуты data-personal-ajax="cart:brief", data-personal-ajax="auth:brief" и т.д.

Установка кода слоя на страницу. Программный интерфейс для обновления.

Для инициализации слоя на странице нужно подключить код библиотеки и создать объект слоя, который следует записать в глобальную переменную для использования в замыканиях. Это стоит сделать пораньше (например, в <head>).

В случае персонального слоя для интернет-магазина код может выглядеть так:

var PERSONAL_AJAX_LAYER = new AjaxLayer({

        'html_data_name': 'personal-ajax', // имя data-атрибута 

        'http_query_key': 'personal_ajax', // ключ для AJAX-запросов

        'server': '/ajax-layer.php',       // адрес для AJAX-запросов

});

(Параметры http_query_key и server описаны в разделе, посвященном серверной части.)

Для обновления слоя нужно вызывать метод .refresh(), указывая имена блоков, которые следует обновить, в виде массива. Например:

.refresh( ['cart', 'buy'] ) — обновить все блоки, имя которых начинается с cart или buy
.refresh( [/^(cart|buy)/] ) — то же самое, но в виде регулярного выражения
.refresh( ['buy*23570'] ) — обновить блоки, имя которых начинается на buy и затем содержит в себе 23570
.refresh('*') — полностью обновить AJAX-слой на данной странице

Вызов метода .refresh() приводит к запросу с сервера актуального HTML-кода перечисленных блоков. (Подробности см. в разделе о серверной части.)

Интеграция с обработчиками событий

В типичном случае события, которые должны вызывать обновление слоя, уже содержат отправку AJAX-запроса, снабженную собственной callback-функцией. Для интеграции слоя в обработчик нужно добавить внутрь этой функции вызов .refresh().

Рассмотрим в качестве примера обработчик формы авторизации, отправка которой происходит по AJAX:

$('body').on('form.auth', 'submit', function() {

        var query = $(this).serialize();

        var address = ... ;

        var post_callback = function() { ... } ;

        $.post(query, address, post_callback);

        return false;

});

В функции, записанной в переменную post_callback, проверяется ответ сервера, и в случае, если он говорит об успешной авторизации, еще одним запросом — с помощью .refresh() — обновляется AJAX-слой:³

var post_callback = function() {

    // ... (проверяем ответ) ...

    // 

    // составляем набор блоков на обновление (в данном случае это легко,   

    // т.к. при авторизации нужно обновить все блоки без исключения)

    var patterns = [ '*' ]; 

    PERSONAL_AJAX_LAYER.refresh(patterns);

};

Другой пример — обработчик кнопки «купить». Нажатие на кнопку сопровождается отправкой на сервер запроса на добавление в корзину товара с данным id:

$('body').on('.buy', 'click', function() {

        var id = ... ; // id товара  

        var query = ... ;

        var address = ... ;

        var post_callback = function() { ... } ;

        $.post(query, address, post_callback);

        return false;

});

После проверки ответа нужно обновить блок с содержимым корзины. Сама кнопка в нормальном случае должна смениться надписью «товар в корзине», поэтому также нужно обновить контейнер этой кнопки, но не контейнеры остальных:⁴ очевидно, добавление в корзину товара никак не может повлиять на присутствие в ней других товаров.

var post_callback = function() {

    // ... (проверки) ...

    var patterns = [ 

        'cart',

        'buy*' + id // кнопку заменяем только у этого товара

    ]; 

    PERSONAL_AJAX_LAYER.refresh(patterns);

};

Callback-функции при обновлении слоя

Можно назначить дополнительные действия, которыми будет сопровождаться обновление блоков. Для этого их список, передаваемый методу .refresh(), нужно снабдить callback-функциями.

Предположим, при нажатии кнопки «купить» она должна заменяться на надпись «товар в корзине» не сразу, а плавно исчезая. Cоответствующая запись в списке блоков, подлежащих обновлению, из строки 'buy*' + id станет массивом, первым элементом которого будет вышеупомянутая строка, а вторым — callback-функция:

var post_callback = function() {

    // ... (проверки) ...

    var layer_callback = function( target, html ) {

        target.fadeOut( function() { target.html(html).fadeIn(); } );

    };

    var patterns = [ 

        'cart', // корзину описываем скалярной величиной, т.к. callback не нужен 

        [ 'buy*' + id, layer_callback ] // элемент для кнопки теперь массив из двух элементов

    ]; 

    PERSONAL_AJAX_LAYER.refresh(patterns);

};

Callback-функция должна принимать два аргумента: первый — jQuery-объект элемента (в данном случае им выступает контейнер кнопки), второй — HTML-код для этого элемента, полученный с сервера.

Стандартное (без callback) обновление слоя выполняется функцией

function( target, html ) { target.html(html); }

Callback-функция применяется ко всем элементам, соответствующим переданному с ней в паре шаблону.

Серверная часть

Как уже было сказано ранее, содержимое блоков получается с сервера отдельным HTTP-запросом.

Этот запрос всегда делается методом POST и отправляется по одному и тому же пути, который указывается при создании объекта слоя в качестве параметра server.

Единственным параметром запроса является массив с именем, указанным в http_query_key при создании объекта. Он содержит информацию о членах AJAX-слоя, присутствовавших на странице на момент формирования запроса.

Для страницы, на которой имеются корзина, незаполненная форма авторизации и несколько товаров, POST-запрос будет выглядеть так:

Array(

    [personal_ajax] => Array(

        [0] => Array( [name] => cart:brief )

        [1] => Array( [name] => buy:23570  )

        [2] => Array( [name] => buy:13450  )

        [3] => Array( [name] => buy:60389  )

        ...

        [5] => Array( [name] => auth:brief, 

                      [inputs] => Array( [email] =>  [password] => ) 

                    )

    )

)

Ключ name содержит имя блока и позволяет, таким образом, однозначно этот блок идентифицировать и сгенерировать для него HTML-код.

В inputs передаются текущие значения полей форм, если таковые имеются внутри блока. Их наличие позволяет при обновлении AJAX-слоя сохранять содержимое частично заполненных форм. (Если серверная часть написана на языке PHP, рекомендуется использовать специальное средство для генерации HTML-форм.)

В ответ нужно вернуть массив похожей структуры — добавить каждому элементу ключ html, в который записать HTML-код блоков:⁵

Array(

    [0] => Array( [name] => cart:brief, [html] => ... )

    [1] => Array( [name] => buy:23570,  [html] => <button ...>купить</button>  )

    [2] => Array( [name] => buy:13450,  [html] => <button ...>купить</button>  )

    [3] => Array( [name] => buy:60389,  [html] => товар в корзине  )

    ...

    [5] => Array( [name] => auth:brief, [html] => <form class="auth">...</form> )

)

Ответ должен быть предусмотрен для всех возможных состояний каждого из блоков, входящих в состав слоя.

1.▲ Необходима также библиотека jQuery.

2.▲ На одной странице может существовать много AJAX-слоев, принадлежность к каждому из которых будет определяться наличием data-атрибута с определенным именем. При этом один и тот же блок может входить в состав нескольких слоев (имея data-атрибуты с соответствующими именами).

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

4.▲ Следует отметить, что использование строковой нотации вида 'buy*' + id может приводить к избыточному обновлению: например, в случае товара c id = 2 с сервера будет запрошен HTML-код не только для него, но и для товаров с любым id, содержащим двойку: 12, 23 и т.д.
Как правило, эта особенность не играет никакой роли. Но если этого все-таки требуется избежать, нужно использовать регулярное выражение — new RegExp('^buy:' + id + '$').

5.▲ Если ответ сервера для некоторого блока вообще не содержит ключа html, при разборе ответа этот блок игнорируется и его содержимое в итоге не меняется.

Генерация HTML-кода форм с помощью языка PHP

Sat, 11 Oct 2014 02:44:27 +0400

Генерация HTML-кода форм с помощью языка PHP

Построение формы с сохранением уже введённых значений — не такая уж простая задача, особенно если приходится иметь дело со списками значений для выбора или c полями, соответствующими массивам. Предлагаемые инструменты позволяют свести решение этой проблемы к описанию полей формы в виде простых конфигураций и подключению нужных HTML-шаблонов.

Состав пакета

В состав инструментария входят:

функция для генерации данных полей (код доступен в виде отдельного PHP-файла)
HTML-шаблоны полей (в виде архива)
обработчик шаблонов (ему посвящена отдельная статья, в которой и опубликован его код)

Основные принципы составления конфигурации полей

Предположим, нужно получить вот такую форму:

Для этого потребуется следующий код PHP:

# 1. Получаем данные полей формы

    require_once 'make_form_data.php'; # Подключаем код функции

    $cfg = array # Составляем конфигурацию полей

        (   

            // первая группа

            'short_note',

            'longer_text',

            'some_file',

            'flag',

            // вторая группа

            'period'   => array('values' => array(

                                        'день', 

                                        'неделя',

                                        'месяц',

                                        'год',

                                     )),

            'shape'    => array('values' => array(

                                        'round' => 'круглый',

                                        'square' => 'квадратный',

                                        'triangle' => 'треугольный'

                                     )),

            'size'     => array('values' => array(

                                        array('value' => '', 'title' => '-- размер --'),

                                        array('value' => 'small', 'title' => 'маленький'),

                                        array('value' => 'medium', 'title' => 'средний'),

                                        array('value' => 'big', 'title' => 'большой'),

                                      )),

            'color'    => array('attr' => array('size' => 5), // число видимых элементов 

                                                              // у <select>  

                                'values' => array(

                                        'black',

                                        'white',

                                        'red' => 'красный',

                                        'blue' => 'синий',

                                        array('value' => 'green', 'title' => 'зеленый')

                                     )),

        );

    $FORMDATA = make_form_data($cfg, $_POST); # Генерируем данные полей  

                                              # с учетом параметров HTTP-запроса

# 2. Получаем HTML-код формы

    require_once 'websun.php'; # Подключаем обработчик шаблонов 

    $HTML = websun_parse_template_path($FORMDATA, 'form.tpl'); # Подставляем данные 

                                                               # в HTML-шаблон формы

С точки зрения составления конфигурации поля делятся на две группы:

Одиночные поля:
- <input type="text">
- <input type="checkbox">
- <textarea>
- <input type="file">
Составить конфигурацию для этих полей очень просто — надо всего лишь указать их имена¹.
Списки значений для выбора. Значения перечисляются в параметре values, каждое из них может быть указано в формате array('value' => 'значение', 'title' => 'подпись'),
'значение' => 'подпись' или просто 'значение'. Такими полями являются:
- набор <input type="radio">
- набор <input type="checkbox"> для выбора нескольких значений одновременно
- <select> и <select multiple>

В шаблоне формы каждому из полей соответствует запись вида {* + *имя* | шаблон *}:

<form method="POST"> <!-- - Для лучшей читаемости HTML-разметка таблицы не приводится -->

    Текст 

    {* + *short_note*  | fields/input.tpl *}

    Многострочный текст 

    {* + *longer_text* | fields/textarea.tpl *}

    Загрузка файла 

    {* + *some_file*   | fields/file.tpl *}

    Флаг (вкл./выкл.) 

    {* + *flag*        | fields/checkbox.tpl *}

    Радиокнопки 

    {* + *period*      | fields/radios.tpl *}

    Выбор нескольких значений 

    {* + *shape*       | fields/checkbox-multiple.tpl *}

    Выпадающий список 

    {* + *size*        | fields/select.tpl *}

    Список с возможностьюодновременного выборанескольких значений

    {* + *color*       | fields/select-multiple.tpl *}

    <button>Отправить</button>

</form>

Атрибуты полей

Случается, что полю нужно присвоить какой-то атрибут, будь то класс, стиль или текст-заглушка. Сделать это можно, включив в конфигурацию поля параметр attr, в котором нужные атрибуты следует перечислить в формате 'имя' => 'значение'². Например, конфигурация

'input_2' => array(

    'attr' => array(

            'placeholder' => 'пишите сюда',

            'class' => 'special',

            'style' => 'border: 2px solid #808080; padding: 2px',

        ),

)

в сочетании с шаблоном input.tpl даст:

<input

 type="text"

 name="input_2"

 value=""

  placeholder="пишите сюда" class="special"  style="border: 2px solid #808080; padding: 2px" 

>

Значения атрибутов перед вставкой обрабатываются функцией htmlspecialchars().³

Поля, соответствующие ассоциативным массивам

Форма может содержать поля для указания нескольких значений одного и того же свойства, которые в HTTP-запросе удобно получать в виде ассоциативного подмассива.

Например, ограничение по цене удобно иметь в виде

[price] => Array

      (

            [min] => ...

            [max] => ...

      )

Получить соответствующий набор полей можно, указав в конфигурации параметр keys:

'price' => array(

        'keys' => array('min', 'max'),

    );

В массиве для подстановки в шаблон добавится уровень вложенности, и к полям нужно будет обращаться по ключам:

{* + *price.min* | fields/input.tpl *}

{* + *price.max* | fields/input.tpl *}

Бывает нужно дифференцировать отдельные поля, указав те или иные индивидуальные свойства. В этом случае элементы массива keys принимают формат описания конфигурации поля⁴. Например:

'price' => array(

        'keys' => array(

                'min' => array(

                        'attr' => array(

                                'placeholder' => 'от',

                            ),

                    ),

                'max' => array(

                        'attr' => array(

                                'placeholder' => 'до',

                            ),

                    ),

            ),

    );

Ключей может быть более двух: 'keys' => array('min', 'max', 'avg', ...) и т.д.⁵

1. ▲ Сокращенной записи вида 'имя' соответствует полная форма 'имя' => array()

2. ▲ Атрибуты, которые обычно применяют без значений, указываются с дублированием:
'readonly' => 'readonly', 'disabled' => 'disabled' и т.п.

3. ▲ Это удобно, в частности, когда в качестве атрибута нужно использовать JSON. Например:

'attr' => array(

        'class' => 'special',

        'data-one' => '{"a":1,"b":2}',

        'data-two' => '{"c":20,"d":30}',

    )

Благодаря обработке htmlspecialchars() кавычки из JSON встанут в значение атрибута без проблем.

4. ▲ При этом параметры, не указанные в элементе keys, наследуются от родительской конфигурации.

5. ▲ Вложенность ключей может быть многоуровневой:

'price' => array(

        'keys' => array(

                'min',

                'max' => array(

                        'keys' => array(

                                'deep', 

                                'deeper' => array(

                                        'keys' => array(

                                                'very_deep',

                                                ...

                                            ),

                                    ),

                            ),

                    ),

            ),

    )

Организация пространства адресов страниц веб-сайта средствами PHP и MySQL/MariaDB

Thu, 31 Jul 2014 06:05:09 +0400

В статье излагается подход, при котором запросы к сайту обрабатываются централизованно (через один PHP-файл), а адреса и содержимое страниц хранятся в базе данных. При этом адрес страницы может быть динамическим, а содержимое — включать в себя метки для подстановки переменных. Странице также может быть назначен исполняемый PHP-код.

Настоящий подход опирается на два программных компонента: маршрутизатор и обработчик шаблонов. Они будут описаны в статье далее.

Виртуальное пространство адресов и централизация обработки запросов

При данном подходе адреса страниц не привязаны к файловой системе, поэтому такое адресное пространство можно называть виртуальным.

Для организации виртуального пространства адресов прежде всего нужно изменить обычное поведение веб-сервера, при котором он интерпретирует адреса запрашиваемых страниц как пути к физическим файлам и каталогам. Вместо этого от веб-сервера требуется, чтобы при получении HTTP-запроса он исполнял некоторый PHP-код и использовал результат работы этого кода для формирования HTTP-ответа.

Исключение составляют реально существующие физические файлы (например, изображения, и др.), которые серверу следует продолжать отдавать напрямую, не задействуя PHP.

Настройка Apache

Описанная задача решается с помощью модуля mod_rewrite. Один из способов — разместить в корневом каталоге веб-сервера файл .htaccess примерно следующего содержания^1,2,3:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f [OR]

RewriteCond %{REQUEST_FILENAME} \.php$

RewriteRule .* _showpage.php

Настройка nginx

Директивы для nginx выглядят следующим образом:

set $vertex /_showpage.php;

set $php_socket unix:/run/php/php5.6-fpm.sock;

location / {

    index $vertex; 

    error_page 404 = @vertex;

    location ~ \.php$ {

        return 404;

    }

}

location @vertex {

    fastcgi_pass $php_socket;

    fastcgi_param SCRIPT_FILENAME $document_root$vertex;

    include fastcgi_params;

}

Маршрутизатор

Любой сайт есть совокупность страниц, имеющих адреса. Механизм сайта должен уметь анализировать приходящий HTTP-запрос и определять, к какой конкретно странице он относится.

Средство, позволяющее задать пространство адресов страниц и сопоставляющее адрес приходящего запроса этому пространству, называется маршрутизатором (или роутером).

В рамках настоящего подхода результатом работы маршрутизатора является HTTP-код ответа и данные для генерации HTML-кода страницы. Эти данные затем передаются обработчику шаблонов, который подставляет их в шаблон, формируя таким образом конечный HTML:

$mysqli = mysqli_connect( ... ); // можно также использовать mysql_connect

require_once 'router.php'; // подключаем код маршрутизатора

$router_cfg = array( ... );   // перечисляем настройки маршрутизатора (см. ниже)

$R = new Router($router_cfg); // создаем объект маршрутизатора 

$R->analyzeURL(); // проводим анализ адреса; в результате объект 

                  // содержит данные страницы - свойство pageData 

                  // и путь к файлу с шаблоном - свойство template

require_once 'websun.php'; // подключаем код шаблонизатора 

$HTML = websun_parse_template_path( // формируем HTML-код страницы

        $R->pageData, // данные страницы для подстановки

        $R->template  // путь к файлу с шаблоном

    );

echo $HTML;

Код маршрутизатора можно скачать одним файлом (требуется также библиотека для работы с MySQL), код шаблонизатора можно скачать здесь. Техника использования будет подробно описана ниже.

Организация хранения страниц

По большому счету, страница сайта — это HTML-код, имеющий адрес.

HTML-код страницы всегда имеет определенную структуру: каркас остается неизменным, а меняются лишь некоторые части. Обычно его можно описать следующим шаблоном:

<!DOCTYPE HTML>

<html>

<head>

    <title>{* заголовок *}</title>

    <meta name="description" content="{* описание для поисковых систем *}">

    <meta name="keywords" content="{* ключевые слова *}">

    <!-- далее может следовать подключение CSS и javascript-файлов и др. -->

</head>

<body>

    {* содержимое *}

</body>

</html>

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

Рассмотрим конфигурацию маршрутизатора в самом простом случае:

$router_cfg = array(

        'table' => 'pages', // имя таблицы со страницами

        'template' => '$/templates/_page.tpl', // путь к файлу шаблона 

    );                                        // ($ - корневой каталог веб-сервера)

Таблица pages должна иметь следующий минимальный набор колонок:

CREATE TABLE pages (

    url VARCHAR(255) NOT NULL,

    title TEXT,

    description TEXT,

    keywords TEXT,

    content MEDIUMTEXT,

    code TEXT,             -- назначение полей 

    template VARCHAR(255), -- code, template и headers 

    headers TEXT,          -- разъясняется далее

    UNIQUE KEY (url)

);

Шаблон страницы содержит метки для подстановки данных:

<!DOCTYPE HTML>

<html>

<head>

    <title>{* + >*title* *}</title>

    <meta name="description" content="{* + >*description* *}">

    <meta name="keywords" content="{* + >*keywords* *}">

    <!-- далее может следовать подключение CSS и javascript-файлов и др. -->

</head>

<body>

    {* + >*content* *}

</body>

</html>

Более подробно языковые конструкции шаблона обсуждаются ниже.

Страницы со статическим адресом

Перейдем теперь непосредственно к технике создания страниц и рассмотрим самый простой случай — страницу со статическим адресом.

Для иллюстрации этого примера как нельзя лучше подходит главная страница, которая есть у любого сайта. Чтобы создать главную страницу, необходимо вставить в таблицу pages вот такую строку:

INSERT INTO pages SET

    url = '/',

    title = 'webew.ru — портал о веб-технологиях',

    description = 'Портал посвящен веб-технологиям.

                   Здесь можно задать вопросы или поделиться своими идеями',

    keywords = 'веб-технологии, php, mysql, html, css, javascript',

    content = '

                <h1>Вас приветствует webew.ru</h1>

                <h2>Последние статьи</h2>

                <ul>

                   ...

                </ul>

                <h2>Новые темы и комментарии</h2>

                <ul>

                   ...

                </ul>

                ...

                <footer>2014 &copy; webew.ru</footer>

              ';

Кириллические (и другие нелатинские) символы в адресах страниц следует указывать без url-кодирования: /мы, а не /%D0%BC%D1%8B, и т.п.

GET-паметры не считаются частью адреса страницы. Другими словами, адреса /page.html, /page.html?a=1 и /page.html?b=2&c=3 с точки зрения маршрутизатора соответствуют одной и той же странице. (Это, однако, вовсе не означает, что GET-параметры нельзя использовать: с ними следует работать, назначив странице исполняемый PHP-код.)

Переменные в данных страницы. Назначение странице исполняемого кода.

Вообще говоря, title, description, keywords и content страниц сами по себе обрабатываются как полноценные шаблоны и могут содержать метки для подстановки переменных, наряду с прочими инструкциями. Например:

INSERT INTO pages SET

    url = '/',

    title = '{*SITENAME*} — портал о веб-технологиях',

    description = 'Портал посвящен веб-технологиям.

                   Здесь можно задать вопросы или поделиться своими идеями',

    keywords = 'веб-технологии, php, mysql, html, css, javascript',

    content = '

                <h1>Вас приветствует {*SITENAME*}</h1>

                <h2>Последние статьи</h2>

                <ul>

                    {* + $/mainpage/newarticles.tpl *}

                </ul>

                <h2>Новые темы и комментарии</h2>

                <ul>

                    {* + $/mainpage/newposts.tpl *}

                </ul>

                ...

                <footer>{*year*} &copy; {*SITENAME*}</footer>

              ';

Инструкция вида {* + $/mainpage/newarticles.tpl *} предписывает вызвать вложенный шаблон, находящийся по адресу mainpage/newarticles.tpl относительно корневого каталога веб-сервера (сокращение "$")⁴. Также поддерживаются условия, циклы и многое другое⁵; подробнее эти возможности описаны в уже упоминавшейся выше статье про обработчик шаблонов.⁶

Теперь о том, как же задавать значения для подстановки.

Посмотрим еще раз, как выглядит вызов обработки шаблона:

$HTML = websun_parse_template_path( 

        $R->pageData, // данные страницы для подстановки

        $R->template  // путь к шаблону

    );

Массивом для подстановки служит свойство pageData объекта маршрутизатора.

Каждой странице можно назначить исполняемый PHP-код. Этот код может выполнять совершенно любые действия (никакие ограничения не накладываются), но прежде всего он используется как раз для заполнения массива pageData.

Назначить исполняемый код можно несколькими способами.

Первый способ — записать в поле code страницы путь к некоторому PHP-файлу. Например:

INSERT INTO pages SET

    url = '/',

    ...

    code = '$/mainpage/get-data.php';

Этот файл будет подключен маршрутизатором с помощью require.⁷

Предположим, на главной странице нужно показать общее количество опубликованных статей и сообщений:

INSERT INTO pages SET 

    url = '/',

    ...

    content = '<h1>...</h1>

               ...

               <p>Статьи: {*articles_total*}, сообщения: {*posts_total*}.</p>

               <footer>...</footer>

              ';

Тогда содержимое mainpage/get-data.php будет примерно таким:

<?php

$arts = ...;  // тут некоторым образом получаем

$posts = ...; // общее количество статей и сообщений

// а теперь записываем полученную информацию в объект маршрутизатора

$this->pageData["articles_total"] = $arts;

$this->pageData["posts_total"] = $posts;

$this->pageData["SITENAME"] = "webew.ru"; // добавляем в массив также 

$this->pageData["year"] = date('Y');        // элементы с ключами SITENAME и year

?>

Как видно из примера, обращение к объекту маршрутизатора осуществляется через ссылку $this⁸.

Следует отметить, что title, description, keywords и content страниц также содержатся в массиве pageData, но изменять эти элементы непосредственно в исполняемом коде не рекомендуется.

Глобальные переменные, при необходимости, делаются доступными с помощью инструкции global (аналогично тому, как это делается в функциях и классах).

Второй способ назначить странице исполняемый код — это записать его прямо в поле code, заключив в <?php ?>:

INSERT INTO pages SET 

    url = '/',

    ...

    content = '<h1>...</h1>

               ...

               <p>Статьи: {*articles_total*}, сообщения: {*posts_total*}.</p>

               <footer>...</footer>

              ',

    code = '<?php

            $arts = ...;

            $posts = ...;

            $this->pageData["articles_total"] = $arts;

            $this->pageData["posts_total"] = $posts;

            $this->pageData["SITENAME"] = "webew.ru";

            $this->pageData["year"] = date(Y);

            ?>' ;

Есть и третий способ. О нем будет рассказано в следующем разделе.

Страницы с динамическим адресом

Страница может обслуживать набор однородных сущностей.

Предположим, сообщения, публикуемые на сайте, имеют адрес вида /posts/(id сообщения).html. Тогда соответствующая запись в таблице будет выглядеть примерно так:⁹

INSERT INTO pages SET

    url = '/posts/(\d+).html',

    code = 'Posts->getData(1) [post]',

    title = '{*post.title*}',

    description = '{*post.snippet*}',

    keywords = '{*post.tags*}',

    content = '<h1>{*post.title*}</h1>

               <p class="date">{*post.date*}</p>

               <div class="text">{*post.text*}</div>

               ...

              ';

Здесь в качестве url страницы указано Perl-совместимое регулярное выражение (PCRE).

Следует отметить, однако, что в данном случае по одному лишь виду пути запроса нельзя определить, что отдать в ответ — нужно еще как минимум убедиться в том, что имеется конкретная сущность (в данном случае сообщение), а также получить ее данные. Для этого нужно назначить странице исполняемый PHP-код.

Запись Posts->getData(1) [post], содержащаяся в code, реализует вышеупомянутый третий способ назначения странице исполняемого кода и в совокупности с url = '/posts/(\d+).html' означает буквально следующее: «проанализировать адрес запроса регулярным выраженем ^/posts/(\d+).html$¹⁰, в случае совпадения создать объект класса Posts и вызвать его метод getData, передав методу в качестве аргумента элемент массива вхождений с индексом 1 (то есть, строку, соответствующую первой паре скобок регулярного выражения); если результат работы getData не пуст — записать его в pageData['post'] объекта маршрутизатора».

Можно также использовать запись вида Posts->getData(1) [post] $/posts/single.php, которая, в дополнение к вышеперечисленному, предписывает в случае успеха подключить файл posts/single.php¹¹.

Нулевой элемент массива вхождений всегда содержит полный путь запроса без ведущего слэша, поэтому при необходимости анализа полного пути можно обращаться к нулевому элементу: Posts->getData(0). Если индекс не указан — Posts->getData() — в качестве аргумента методу будет передан весь массив вхождений целиком.

Альтернативные шаблоны страниц

Отдельным страницам можно назначать альтернативные шаблоны для каркаса HTML-разметки.

Представим себе, что на всех страницах сайта, кроме главной, присутствует левая колонка, незименная от страницы к странице:

<!DOCTYPE HTML>

<head>...</head>

<body>

    <!-- header одинаковый у всех страниц без исключения, 

         поэтому его вынесем в отдельный шаблон -->

    {* + $/templates/header.tpl *} 

    <div id="left-column">

        <!-- левая колонка не обязательно статична по своему содержимому

             здесь вполне могут быть переменные, например: -->

        {*left_menu*}

    </div>

    <div id="center-column">

        <!-- а здесь собственно содержимое страницы - 

             то, что в ячейке content таблицы в БД -->

        {* +> *content* *}

    </div>

    <!-- footer - аналогично header -->

    {* + $/templates/footer.tpl *}

</body>

В таком случае следует сделать для главной страницы отдельный шаблон, в котором левой колонки нет:

<!DOCTYPE HTML>

<head>...</head>

<body>

    {* + $/templates/header.tpl *} 

    <!-- а тут левой колонки нет -->

    <div id="center-for-mainpage">

        {* +> *content* *}

    </div>

    {* + $/templates/footer.tpl *}

</body>

Сохраним этот шаблон, например, в файле mainpage/_page.tpl и укажем это в записи для главной страницы, заполнив поле template:

INSERT INTO pages SET

    url = '/',

    ...

    template = '$/mainpage/_page.tpl' ;

У остальных страниц поле template будет пустым, и это послужит инструкцией использовать для них общий шаблон, указанный при создании объекта маршрутизатора — $/templates/_page.tpl.

Постраничное подключение javascript- и css-файлов

Помимо общих файлов, которые можно перечислить в секции <head> прямо в шаблоне, для отдельных страниц могут потребоваться специальные файлы. Чтобы обеспечить их подключение, нужно выполнить два действия:

1. Заполнить для страницы поле headers, перечислив файлы через перевод строки. Например:

INSERT INTO pages SET

    url = '/',

    ...

    headers = '/mainpage/style.css

               http://code.jquery.com/jquery.min.js

               /mainpage/intro.js 

               /mainpage/document-ready.js' ;

Пути к файлам будут вставлены в HTML-код страницы ровно в том виде, в котором они указаны.

При отсутствии расширения в адресе тип файла следует явно указать в начале:
js https://api-maps.yandex.ru/2.1/?load=package.full&lang=ru-RU

2. Отредактировать шаблон страниц, поместив внутрь тега <head> следующую конструкцию:

{%*headers.css*} <link rel="stylesheet" href="{*headers.css:*}" /> {*headers.css*%}

{%*headers.js*} <script src="{*headers.js:*}"></script> {*headers.js*%}

В результате шаблон примет приблизительно такой вид:

<!DOCTYPE HTML>

<html>

<head>

    <title>{* + >*title* *}</title>

    <meta name="description" content="{* + >*description* *}">

    <meta name="keywords" content="{* + >*keywords* *}">

    <!-- тут можно без всяких условий подключить файлы, необходимые для всех страниц -->

    <link rel="stylesheet" href="/css/common.css" />

    <script src="/js/jquery.min.js"></script>

    <!-- а вот указание на постраничные файлы: -->

    {%*headers.css*} <link rel="stylesheet" href="{*headers.css:*}" /> {*headers.css*%}

    {%*headers.js*} <script src="{*headers.js:*}"></script> {*headers.js*%}

</head>

<body>

    ... 

</body>

</html>

Разделение однородного пространства адресов

Встречаются случаи, когда разнородные сущности имеют одинаковые по виду адреса страниц.

Рассмотрим пример. Предположим, речь идет об интернет-магазине, где товары разбиты на категории, у каждой из которых должна быть своя страница с адресом вида /название категории. У каждого производителя товаров тоже должна быть своя страница с адресом вида /название производителя.

Оба этих случая описываются регулярным выражением /[^/]+¹², которое не позволяет отличить один от другого. При этом составить более точные выражения, подходящие для каждого из этих случаев в отдельности, нельзя.¹³

В такой ситуации потребуется выполнить следующие действия.

Для начала нужно добавить в таблицу pages запись, соответсвующую такому адресу, при этом снабдив её специальными инструкциями:

INSERT INTO pages SET

    url = '/[^/]+', 

    code = 'Categories->getData(1)    [cat]          category

            Manufacturers->getData(1) [manufacturer] manufacturer' ;

Формально эта запись является страницей, но фактически она представляет собой «развилку»¹⁴, от которой идут две «дорожки» — к категориям (category) и к производителям (manufacturer).

Разберем эти инструкции подробнее.

Вспомним инструкцию Posts->getData() [post] $/posts/single.php, которая предписывала проверить адрес и в случае успеха записать данные в pageData['post'], передав затем управление файлу posts/single.php.

Похожим образом действует и инструкция Categories->getData(1) [cat] category, однако в третьей ее части стоит не путь к PHP-файлу, а указатель на другую запись в таблице pages^15,16, которой и будет передано управление. Этот указатель представляет собой значение поля url целевой записи.

Вот как примерно выглядит эта запись:

INSERT INTO pages SET

    url = 'category',

    title = '{*cat.title*}',

    description = '{*cat.description*}',

    keywords = '...',

    content = '<h1>{*cat.title*}</h1>

                    ...

              ',

    code = '(здесь можно пользоваться $this->pageData[cat])';

Это обычная страница¹⁷, которой уже доступны данные категории в pageData['cat']. Они используются в полях страницы в виде переменных {*cat.ключ*} и, при необходимости, могут быть задействованы в назначенном ей PHP-коде.

Если проверка адреса с помощью Categories->getData() потерпела неудачу, маршрутизатор немедленно переходит к следующей инструкции — Manufacturers->getData(1) [manufacturer] manufacturer (которой соответствует страница с url = 'manufacturer') и так далее до тех пор, пока проверка адреса не завершится успешно или не закончатся инструкции. В последнем случае код HTTP-ответа будет установлен маршрутизатором в 404.

Выделение подпространства адресов

Бывает, что адреса некоторой группы страниц попадают в другую, более широкую, группу.

Допустим, имеется интернет-магазин, в котором страницы товаров имеют адреса вида /производитель/модель.html, а страницы точек розничной продажи — /shops/(id точки).html. Первые при этом описываются регулярным выражением /[^/]+/[^/]+\.html, а вторые — /shops/\d+\.html. Тогда адрес страницы конкретной розничной точки, например /shops/1.html, совпадет с обоими выражениями.

В таком случае маршрутизатору нужно сообщить, что более строгое выражение должно обрабатываться первым. Для этого его нужно предварить числом. Например:
10 /shops/\d+\.html. Это число маршрутизатор рассматривает как приоритет, обрабатывая первыми страницы с б́ольшим приоритетом.¹⁸

Аналогичного эффекта можно достичь, если менее строгому выражению указать отрицательный приоритет — -10 /[^/]+/[^/]+, а более строгое оставить без изменений.

Ошибка 404

Маршрутизатор считает, что запрошенная страница не существует на сайте, в следующих случаях:

не обнаружена запись в таблице pages
проверка всех инструкций Класс->метод() [ключ] указатель закончилась неудачей

В такой ситуации маршрутизатор установит HTTP-код ответа в 404.

Можно создать специальную страницу, которую маршрутизатор автоматически будет отдавать в таких случаях¹⁹. Её url должен быть равным '404':

INSERT INTO pages SET

    url = '404',

    title = 'Ошибка 404 - страница не найдена.',

    content = '<h1>Ошибка: страница не найдена</h1>

               <p>Страницы с адресом {*$_SERVER.REQUEST_URI*} на сайте нет.</p>

               <!-- в шаблонах можно использовать суперглобальные переменные -->

              ',

   code = '(и в этом случае тоже можно назначать исполняемый код)';

Об адресах для AJAX-запросов

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

Следует принять соглашение, по которому адреса таких запросов содержат некоторый фрагмент (например, "ajax"), дополнив соответствующим образом настройки веб-серверов.

Apache

Нужная директива записывается так: RewriteCond %{REQUEST_URI} !ajax. Весь набор директив примет вид²⁰:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f [OR]

RewriteCond %{REQUEST_FILENAME} \.php$

RewriteCond %{REQUEST_URI} !ajax

RewriteRule .* _showpage.php

nginx

Директиву location для *.php потребуется дополнить, и она примет вот такой вид:

location ~ \.php$ {

    if ($uri !~ ajax) {

        return 404;

    }

    fastcgi_pass $php_socket; 

    fastcgi_param SCRIPT_FILENAME $document_root$uri;

    include fastcgi_params;

}

1.▲ Подробнее об использовании mod_rewrite и .htaccess можно прочитать в этой немного устаревшей статье.

2.▲ Директива RewriteCond %{REQUEST_FILENAME} \.php$ воспрепятствует исполнению файлов *.php в ответ на прямой запрос через веб-сервер.

3.▲ Менее строгим, но и менее ресурсоемким (засчет отсутствия проверки существования физического файла) является явное перечисление фрагментов имен файлов (обычно расширений), встречая которые, веб-серверу не следует задействовать PHP:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !\.(css|js|png|jpg|gif)$

RewriteRule .* _showpage.php

4.▲ При желании можно поместить содержимое страницы во вложенный шаблон полностью. Например:

INSERT INTO pages SET

    url = '/',

    ...

    content = '{* + $/mainpage/content.tpl *}';

5.▲ В том числе инструкция вида {* + >*имя* *}, предписывающая не просто подставить значение переменной, но еще и обработать само это значение как шаблона: искать в содержимом переменной ссылки на другие переменные, а также все остальные синтаксические выражения обычных шаблонов. Именно использование таких инструкций ({* + >*title* *}, {* + >*content* *} и т.п.) в общих шаблонах для страниц обеспечивает динамическую обработку полей title, description, keywords и content.

6.▲ Вообще говоря, в связке с маршрутизатором может быть использован любой схожий по возможностям с websun обработчик шаблонов. Websun является вариантом, к использованию рекомендуемым, но не обязательным. Никаких специальных взаимных требований друг к другу маршрутизатор и обработчик не имеют.

7.▲ Сокращение "$", как и в случае путей к шаблонам, обозначает корневой каталог веб-сервера.

8.▲ Технически файл подключается внутри одного из методов маршрутизатора, поэтому код файла выполняется в контексте объекта.

9.▲ Нотация с точкой соответствует в языке шаблонизатора следующему уровню вложенности массива: {*post.title*} — pageData['post']['title'], {*post.date*} — pageData['post']['date'] и т.п.

10.▲ Механизм маршрутизатора автоматически добавляет символы начала и конца строки перед анализом пути, т.е. запись /posts/(\d+).html на самом деле приведет к сопоставлению с выражением ^/posts/(\d+).html$. Поэтому ошибочное совпадение с частью пути запроса (например, /something/posts/13.html или /posts/13.html/something) исключено.
Сопоставление проводится в режиме регистронезависимости (флаг i).

11.▲ Запись Posts->getData(1) [post] $/posts/single.php в code страницы равносильна следующей:

<?php

// Код будет выполняться только в случае успешного сопоставления

// пути запроса регулярному выражению; при этом маршрутизатор  

// записывает массив с результатами этого сопоставления в свойство matches.

$Obj = new Posts;

$data = $Obj->getData($this->matches[1]);

if ($data) {

    http_response_code(200);

    $this->pageData['post'] = $data;

    require_once "$_SERVER[DOCUMENT_ROOT]/posts/single.php"; 

    // а точнее - $this->requireFile('$/posts/single.php');

}

else

    http_response_code(404);

?>

Аналог для Posts->getData(1) [post], очевидно, выглядит так же, за исключением отсутствия require файла.

12.▲ Круглые скобки нужны в данном случае лишь для того, чтобы дать маршрутизатору указание рассматривать адрес этой страницы как динамический и использовать его в качестве регулярного выражения, а не для простой проверки на равенство (как это делается для страниц со статическим адресом).

13.▲ В подобных случаях из положения обычно выходят, выделяя каждому роду сущностей свое подпространство, что приводит к адресам вида /cat/категория вместо /категория. Такое решение, как правило, обсуловлено именно техническими ограничениями механизма сайта, поскольку более короткие и наглядные адреса обычно являются более предпочтительными.

14.▲ Именно поэтому у неё не указаны никакие поля, кроме url и code.

15.▲ Если третья часть инструкции заканчивается фрагментом .php, она считается путем к PHP-файлу, в противном случае — указателем на страницу.

16.▲ В случае, если указатель ссылается на несуществующую запись, маршрутизатор будет считать, что страница с запрошенным адресом не существует. Подробнее см. соответствующий раздел статьи.

17.▲ Нужно сказать, однако, что доступ к этой странице напрямую невозможен в принципе: любой адрес начинается со слэша, а здесь в поле url ведущего слэша нет. Потому такая страница может быть задействована только через описанное указание-«развилку».

18.▲ Число-приоритет должно быть целым. Его можно отделять от регулярного выражения пробелом — для удобочитаемости.

19.▲ Если специальную страницу не заводить, то маршрутизатор все равно будет отдавать код 404, но пользователь увидит либо пустой экран, либо результат замены меток для подстановки данных в основном шаблоне на пустые строки.

20.▲ Или

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !\.(css|js|png|jpg|gif)$

RewriteCond %{REQUEST_URI} !ajax

RewriteRule .* _showpage.php

для менее ресурсоемкой конфигурации, упоминавшейся ранее.

Thu, 17 Apr 2014 16:33:51 +0400

Всего неделя остается до РИТ++ 2014 в Санкт-Петербурге, программа которой значительно отличается от московского варианта.

Вот что об этом говорят сами организаторы:

Цитата:

Новость первая - оказывается программа в Санкт-Петербурге очень сильна и довольно серьёзно расходится с Московской. Вот, например, список ключевых на наш взгляд, докладов:

Как мы сделали IDE для HTML5 на HTML5 / Константин Лихтер (Intel Corporation)
Сравнение современных систем управления конфигурацией Chef, Puppet, Salt, Ansible / Житинский Сергей Александрович (Git in Sky);
Технический долг. Сколько мы должны и как заплатить по счетам? / Павлов Дмитрий Юрьевич (Smart Step Group);
Архитектура AVITO.ru / Роман Павлушко (AVITO.ru);
Как вырастить команду хороших веб-технологов / Нарек Мкртчян (Quins);
Архитектура и оптимизация большого одностраничного AngularJS-приложения / Антон Плешивцев (Aviasales.ru);
7 принципов разработки собственных key/value решений или 500М счетчиков ещё не предел на примере SophiaDb / Календарев Александр Михайлович (loveplanet.ru);
Защищённое хранение данных и проведение операций в облачных БД / Владислав Андреевич Бойко (Parallels).

Роман из Avito.RUТут и высоконагруженные системы и базы данных (другие), облачные вычисления (тоже другие). Есть несколько докладов, которые вообще не звучали в Москве. Например, "Архитектура AVITO.ru" от Романа Павлушко.

В докладе поговорим о high-level архитектуре проекта AVITO.ru. Что такое AVITO.ru в цифрах:

сотни миллионов динамических запросов в сутки
десятки терабайт статических данных
терабайтные базы данных
тысячи rps на поисковой кластер
десятки гигабайт clickstream-данных в день
миллиарды счетчиков
более 100 достаточно мощных серверов

Чтобы переваривать указанные выше потоки данных и вычислений, но при этом не терять темпы разработки и поддержки продукта, мы постоянно расширяем технологический стек. В настоящее время мы уже плотно сидим на таких продуктах как: nginx, PHP, PostgreSQL, Sphinx, redis, mongodb и пр. Каждый продукт для нас - это оптимальное решение задач разработки и экономии серверных ресурсов.

Fri, 04 Apr 2014 17:32:49 +0400

Как и всегда, цена на участие в конференции возрастает с приближением открытия.
До очередного повышения остается всего 3 дня — спешите!

РИТ 2014++ (скидка внутри!)

Tue, 11 Mar 2014 15:23:27 +0400

Очередная ежегодная конференция веб-разработчиков Российские Интернет-Технологии 2014 будет проходить в апреле этого года, на этот раз не только в Москве (14-15 апреля), но и в Санкт-Петербурге (24-25 апреля).

С приближением конференции цена возрастает, поэтому регистрироваться на нее лучше заранее.
Аудитории webew.ru предоставляется специальная скидка 10%, которая доступна по промо-коду sql_friends.

Подробнее о программе конференции:

Цитата:

Прошла первая встреча докладчиков и Программного комитета, нам набросали пять экранов пожеланий. Тут и доклад от Константина Осипова по обновлённому Tarantool (он успел его переписать), и доклад от Максима Лапшина по базам данных (включая собственную разработку) для хранения временных рядов. Пара относительно новых баз данных (Tiger) и свежие версии промышленных стандартов (PostgreSQL 9.3).

Возобновился интерес слушателей к системам виртуализации и появился к новым принципам и концепциям в построении систем хранения и СУБД - например WriteOnly или OnlySSD. Приз, без сомнения, заслуживает Сергей Аверин с запросом на доклад "Развитие криптовалют в криптостойкие распределённые системы хранения" :) Что ж, попробуем найти.

По серверному программированию интересы слушателей касаются новых языков программирования, фреймворков и концепций ускорения PHP (компиляция PHP в байт-код или компиляция ограниченного набора инструкций PHP в код на C).

По архитектурам и высоконагруженным проектам нам интересны мессенджеры, включая Telegram (поедем на поклон к Николаю Дурову), интересна Олимпиада в Сочи (в России всего два сайта, использующих Olympic Data Feed - количество информации, которую можно найти на сайте sochi2014.com просто колоссально - вплоть до конкретных оценок для конкретных фигуристов за конкретные прыжки или элементы).

Мобильные разработки - здесь аудитория мечтает о фреймворке - ты на нём пишешь, а дальше все само :)

Системное администрирование - опять виртуализация, отказоустойчивость и безопасность, но на этот раз на самом стандартном железе. Устройство интернет и что делать, если упадёт железный занавес. Приз за оригинальность получает заявка на доклад "Как пакистанский админ может отрубить YouTube?". Опять Сочи 2014 - вопреки всем прогнозам, видеотрансляции из Сочи прекрасно работают и Российский интернет тоже. Да, у нас есть специальный отдел, который занимается тем, что уговаривает Игоря Сысоева выступить у нас. Надеемся на то, что заграница (зачёркнуто) Максим Дунин нам поможет :)

Клиентские технологии - заявки по новым фреймворкам, включая фреймворки по HTML и по CSS (оказывается, есть и такие), тестирование JavaScript-кода, визуализация графиков, а также более глубокое изучение последствий перехода на Single Page Application и толстые клиенты. Например, одно из таких последствий - быстрый расход батарейки и такие монстры, как Facebook, уже начинают откат назад, отказ от лишней интерактивности и переход на более простые фреймворки.

Есть также интересное предложение по Highload++ - полный комплект материалов за все время проведения конференции, в который входят:

- Видеозаписи всех докладов с 2007 по 2013 года
- Видеозапись учебного дня 2013 года
- Все презентации всех лет
- Расшифровка лучших докладов
- Одна PDF и одна бумажная книга с лучшими докладами

Приобрести комплект можно по адресу http://conf.ontico.ru/7years/
Стоимость комплекта составляет 25000 руб. На комплект также действует скидка (см. в начале сообщения), поэтому для нашей аудитории он обойдется в 22500 руб.

Легкий ORM для PHP и MySQL

Tue, 31 Dec 2013 00:28:53 +0400

21.12.2025: Продолжение разработки тут - github.com/1234ru/listformdb

В статье приводится реализация объектно-реляционного отображения, выполненная в виде небольшой библиотеки с простым и гибким интерфейсом. Код библиотеки доступен в виде одного php-файла. В качестве интерфейса к базе данных используются удобные функции PHP для работы с MySQL.

Объектно-реляционное отображение (англ. object-relational mapping или ORM) — техника программирования, которая позволяет разработчику абстрагироваться от механизмов работы хранилища данных и писать код в терминах логики конкретного приложения. В частности, заменять написание SQL-запросов вызовом специальных функций/методов.¹

Поиск по параметрам

Самая частая задача при разработке веб-приложений — это построение списка на основании некоторых условий. Такой список может быть разбит на страницы и определенным образом отсортирован.

В качестве примера рассмотрим получение списка товаров для страницы каталога в интернет-магазине, относящейся к определенному производителю.

Предположим, товары хранятся вот в такой таблице:

mysql> SELECT * FROM products;

+----+-----------+-------+----------+-----------------+-------+

| id | title     | price | discount | manufacturer_id | text  |

+----+-----------+-------+----------+-----------------+-------

|  1 | Веник     |   100 |        0 |               1 |       |

|  2 | Швабра    |   500 |        0 |               1 |       |

|  3 | Чайник    |  1500 |       10 |               2 |       |

|  4 | Совок     |   150 |        0 |               1 |       |

|  5 | Телевизор |  5000 |       30 |               3 |       |

|  6 | Ведро     |   200 |        0 |               1 |       |

+----+-----------+-------+----------+-----------------+-------+

Страница каталога снабжена формой поиска, позволяющей ограничивать список товаров по некоторым параметрам:

HTML-код формы:

<form id="example">

    Цена от <input name="price_final[min]">

    до <input name="price_final[max]">

    <input name="has_discount" type="checkbox"> скидка

    <button>OK</button>

    <br>

    Название (начинается с) <input name="title">

</form>

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

require_once 'ORM.php';

$query = array(

        "manufacturer_id = 2",

        'where' => $_GET,

        'orderby' => '[ord]',

        'limit' => [ 'p', ['N',20] ],

    );

$P = new Products;

$products = $P->find($query);

Методу find() передается массив с условиями поиска: конкретные значения параметров, указания по сортировке и LIMIT, а также ограничения выборки, задаваемые вручную.

Ключ where этого массива содержит значения параметров поиска, из которых по определенным правилам формируются условия конечного SQL-запроса (см. конфигурация параметров поиска). При вставке в запрос значения параметров автоматически экранируются², лишние ключи (для которых в конфигурации нет соответствующего параметра) просто игнорируются.

Остальные условия поиска будут подробно рассмотрены в соответствующих разделах статьи (произвольные условия, LIMIT, сортировка).

Класс Products унаследован от специального абстрактного класса библиотеки и содержит в своем определении отображение параметров поиска (читай — полей формы) на структуру базы данных:

Class Products extends _List {

    public $tables = [

        "FROM products p",

        // здесь могут быть также JOIN с другими таблицами

    ];

    public $columns = [

        'id' => [],

        'price_final' => [

            'sql' => "price * (100 - discount) / 100",

            'type' => '[min,max]',

        ],

        'title' => array[

            'type' => 'LIKE%',

        ],

        'has_discount' => array[

            'sql' => "discount > 0",

            'type' => 'on-off'

        ],

    ];

}

Чтобы вместо полных данных строк получить только их идентификаторы, нужно воспользоваться методом findIds(), интерфейс которого полностью аналогичен таковому метода find():

$product_ids = $P->findIds($query, $count);

Для получения полных данных списка на основе уникальных идентификаторов служит метод getList():⁹

$products = $P->getList($product_ids);

// $product_ids внутри метода будут проэкранированы

Идентификатор одиночной сущности можно получить с помощью метода findId():

$product_id = $P->findId($query);

Конфигурация параметров поиска

Теперь обратимся к массиву $columns и рассмотрим конфигурацию каждого из полей детально.

Поле, являющееся уникальным идентификатором записи в главной таблице, обязательно должно присутствовать и следовать в списке первым. Именно поэтому id упоминается в конфигурационном массиве, хотя его нет в форме.

Ключ type определяет, как конкретно указанное SQL-выражение будет сопоставлено значению соответствующего параметра (эти значения входят в условия для построения списка (массив $query) и передаются в ключе where). Сопоставление бывает четырех видов.

Равенство

type, не установленный вовсе (как в случае с id) или равный FALSE в результате даст условие со знаком «равно», а если значения параметра является не скалярной величиной, а массивом, то IN.

Например, если бы $_GET содержал в ключе id число 10, получилось бы условие

WHERE (p.id = 10)

а если бы — массив array("Атос", "Д'Артаньян"), то³

WHERE (p.id IN ('Атос', 'Д\'Артаньян'))

Поддерживается и NULL — array("Атос", NULL, "Д'Артаньян") превратится в условие:

WHERE (p.id IS NULL OR p.id IN ('Атос', 'Д\'Артаньян'))

Сопоставление типа LIKE

Другой вариант сопоставления параметра содержит конфигурация поля title:

'title' => array(

        'type' => 'LIKE%',

        ...

    )

Такая конфигурация даст условие вида

title LIKE 'параметр%'

где 'параметр' — это экранированный $_GET['title']⁴.

Если $_GET['title'] является массивом, условие будет составлено для каждого из его элементов, и затем все они объединены через OR (получится как бы IN для LIKE):

(title LIKE 'параметр[0]%') OR (title LIKE 'параметр[1]%') OR ...

Аналогичным образом можно использовать '%LIKE' и '%LIKE%'.

Интервальное сопоставление

Конфигурация поля price_final является примером интервального сопоставления:

'price_final' => array(

        'sql' => "price * (100 - discount) / 100",

        'type' => '[min,max]',

        ...

    )

Указанные ключи параметра ограничивают выборку: первый — снизу, второй — сверху. Условие в данном случае примет вид:

price * (100 - discount) / 100 >= $_GET[price_final][min]

AND

price * (100 - discount) / 100 <= $_GET[price_final][max]

Вместо min и max можно указывать любые другие имена ключей, нужно лишь следить за тем, чтобы они совпадали с именами полей формы.

Можно указать только один ключ (например, '[min,]'), в этом случае будет возможность ограничить выборку только с одной стороны.

Если квадратные скобки заменить на круглые — '(min,max)' — нестрогое неравенство заменится на строгое (так же, как обозначают интервалы в математике). При этом они не обязательно должны быть одинаковыми: с одной стороны неравенство может быть строгим, а с другой — нет.

Сопоставление типа «включено/выключено»

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

Для поля has_discount с конфигурацией

'has_discount' => array(

        'sql' => "discount > 0",

        'type' => 'on-off'

    )

в запрос попадет условие WHERE (discount > 0).

Это сопоставление лучше всего подходит для полей формы типа checkbox.

Произвольные условия

Ограничения списка могут не только формироваться на основании параметров поиска, но и быть прямо указаны вручную.

В рассматриваемом примере страница каталога относится к какому-то конкретному производителю. В этом случае условие на manufacturer_id должно выполняться всегда — независимо от содержимого $_GET:

$query = array(

        "manufacturer_id = 2",

        'where' => $_GET,

        ...

    );

Таких произвольных условий может быть сколько угодно. Все они войдут запрос непосредственно в том виде, в котором указаны, без изменений.

Разбивка на страницы, LIMIT, получение общего количества строк

Для разбивки на страницы в условия для построения списка нужно включать элемент limit. В случае, если номер страницы передается в GET-параметре p, а количество записей на странице может содержаться в параметре N, код может выглядеть следующим образом:⁵

$query = array(

        'limit' => array(

                'page'     => ( isset($_GET['p']) ? $_GET['p'] : 1),

                'per_page' => ( isset($_GET['N']) ? $_GET['N'] : 20),

            ),

        ...

    );

То же самое можно записать в сокращенной форме (как это и сделано в примере):

$query = array(

        'limit' => [ 'p', ['N',20] ], // [...] - короткий вариант объявления массивов

        'where' => $_GET,             // в PHP с версии 5.4

        ...

    );

При такой форме записи имена ключей в limit относятся к массиву с параметрами поиска (where).

Запись вида [ 'p', ['N',20,100] ] устанавливает для количества записей ограничение сверху.

Можно указывать числовые значения явно: 'limit' => '0, 20' или 'limit' => 100. Такая запись перейдет в LIMIT запроса в неизменном виде.

Общее количество строк без учета LIMIT можно получить, передав методу find() необязательный второй аргумент — переменную, в которую это количество будет записано:⁶

// $count необязательно должна быть установлена ранее

$products = $P->find($query, $count);

Сортировка

Указывать сортировку в условиях запроса следует в ключе orderby. При этом можно ссылаться на элементы массива $columns. Например:

$query = array(

        'orderby' => "{*price_final DESC*}, id DESC",

        'where' => ...

        ...

    );

Фрагмент {*price_final DESC*} заменится на соответствующее SQL-выражение из массива $columns.

Чтобы дать возможность управлять сортировкой через параметры GET-запроса страницы, в ключ orderby нужно поместить специальную метку:

$query = array(

        'orderby' => '&ord',

        'where' => $_GET,

        ...

    );

Здесь ord — ключ массива $_GET, содержащий текущие параметры сортировки.

Соответственно, адрес страницы должен иметь вид ...&ord=(имя поля из конфигурации) (направление). Например, ...&ord=price_final DESC. Метка в orderby заменится SQL-выражением для выбранного поля⁷, в результате запрос примет вид:

ORDER BY price * (100 - discount) / 100 DESC

Можно комбинировать метку и постоянные части:

$query = array(

        ...

        'orderby' => "&ord, discount > 0 DESC, ...",

    );

А также задавать сортировку по умолчанию для случая, если она не указана через GET-параметр:

$query = array(

        ...

        'orderby' => "&ord || discount > 0, id DESC",

    );

Получение и обработка данных

Набор полей списка

Каждому параметру поиска соответствует одноименное поле в результирующем массиве данных. Взглянем еще раз на конфигурацию⁸:

public $columns = array(

    'id' => array(

            'sql' => "p.id",

            ...

        ),

    'price_final' => array(

            'sql' => "price * (100 - discount) / 100",

            ...

        ),

    'title' => array(

            ...

        ),

    'has_discount' => array(

            'sql' => "discount > 0",

            ...

        ),

);

Вот как примерно выглядит результат работы метода find():

    ...

    [5] => Array

        (

            [id] => 5

            [price_final] => 35000

            [title] => Телевизор

            [has_discount] => 1

        )

    [4] => Array

        (

            [id] => 4

            [price_final] => 1500

            [title] => Совок

            [has_discount] => 0

        )

    ...

Если поле нужно в качестве параметра поиска, но среди конечных данных не требуется, его можно исключить из результирующего массива, поместив в начало ключа специальную последовательность @@:

public $columns = array(

    'id' => ...

    ...

    '@@: has_discount' => array(

            'sql' => "discount > 0",

            ...

        ),

);

При такой конфигурации элемент has_discount среди полученных данных будет отсутствовать.

Получение данных одиночной сущности

Для получения данных одиночной сущности по её идентификатору служит метод getSingle():

$P = new Products;

$product = $P->getSingle($product_id);

Поля, которые для списка не требутся и нужны только для случая одиночной сущности, можно выделить явным образом. Их объявление должно начинаться с последовательности @::

public $columns = array(

    ...

    "@: p.text",

);

Поле p.text при поиске и работе со списками запрашиваться из БД не будет, что даёт определенный выигрыш в быстродействии.

Пост-обработка данных

К каждой строке, полученной из БД, могут быть применены дополнительные преобразования. Для этого нужно определить метод processData(). Например:

class Products extends _List {

   ...

   function processData($row) {

       $row['url'] = "/products/$row[id].html";

       return $row;

   }

}

Каждой записи результирующих данных добавится ключ url

    ...

    [5] => Array

        (

            [id] => 5

            [price_final] => 35000

            [title] => Телевизор

            [has_discount] => 1

            [url] => /products/5.html

        )

    [4] => Array

        (

            [id] => 4

            [price_final] => 1500

            [title] => Совок

            [has_discount] => 0

            [url] => /products/4.html

        )

    ...

Пост-обработка выполняется после приведения типов.

Получение специальных данных

Периодически бывает нужно получить не просто список сущностей со всеми полями, а какой-то специальный набор их данных. Для этого служит метод getSpecialData().

На вход метод принимает набор SQL-выражений для будущих колонок результата, а также массив с условиями поиска (аналогичный тому, что используется для методов find() и findIds()).

Например, для заданных условий поиска получить ценовой диапазон и количество товаров со скидкой от 50% можно с помощью следующего кода:

$query = array(-

        "manufacturer_id = 2",

        'where' => $_GET,

        ...

    );

$special_data = $P->getSpecialData(

        array(

            "SUM(discount >= 50) AS sale_count",

            "MIN({*price_final*}) AS price_min",

            "MAX({*price_final*}) AS price_max",

        ),

        $query

    );

Здесь {*price_final*} — ссылка на SQL-выражение в массиве $columns.

Содержимое $special_data будет примерно следующим:

Array

(

    [0] => Array

        (

            [sale_count] => 35

            [price_min] => 1000

            [price_max] => 12500

        )

)

Получить текст SQL-запроса вместо результата можно с помощью метода getSpecialDataSQL(), принимающего те же аргументы, что и getSpecialData().

Если результат заведомо состоит из одной строки, удобно использовать метод getSpecialDataRow(), он вернёт массив меньшего уровня вложенности.

Другой пример — получение всех производителей (точнее, их идентификаторов), товары которых удовлетворяют определенным условиям:

$query = ...;

$special_data = $P->getSpecialData(

        "DISTINCT p.manufacturer_id",

        $query

    );

Здесь методу передается одна колонка вместо массива, что является инструкцей вернуть вместо табличного результата колоночный:

Array

(

    [0] => 2

    [1] => 5

    [2] => 10

)

Для получения результата, который состоит из одной ячейки, предназначен метод getSpecialDataCell(). Первый аргумент для него - строка с SQL-выражением, а не массив таких строк:

$query = ...;

$special_data = $P->getSpecialDataCell("COUNT(*)", $query);

DDL: изменение структуры данных таблицы

ORM снабжен средствами генерации запросов, изменяющих структуру хранения данных (DDL — data definition language).

CREATE TABLE для главной таблицы

ORM позволяет выполнить SQL-запрос на создание главной таблицы или получить его содержимое.

Для этого в конфигурации соответствующих полей нужно указать ключ column_definition, а также создать специальное свойство класса под названием $mainTableConfig:

    public $mainTableConfig = [

        'name' => 'products',

        'alias' => 'p',

        'keys' => [ // определения ключей списком

            'KEY (price)',

            'KEY (discount)'

        ],

        'properties' => [

            'ENGINE' => 'MyISAM', // можно в виде пар ключ=значение

            'AUTO_INCREMENT = 7', // а можно просто строкой

        ]

    ];

    public $columns = [

        'id' => [

            'sql' => "p.id",

            'column_definition' => 'INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY',

        ],

        'title' => [

            'column_definition' => 'VARCHAR(255) NOT NULL'

        ]

    ];

Создать таблицу можно так:

$P->createMainTable();

Вызвав вместо этого метод generateMainTableSQL(), получим текст запроса:

CREATE TABLE IF NOT EXISTS products (

  id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,

  title VARCHAR(255) NOT NULL,

  KEY (price),

  KEY (discount)

) ENGINE = MyISAM AUTO_INCREMENT = 7

Запрос без IF NOT EXISTS в обоих методах можно получить, передав false в качестве аргумента.

Модификация колонок таблицы

Методы changeOrModifycolumn() и changeOrModifycolumnsQL() служат для исполнения запросов CHANGE/MODIFY/RENAME column.

Рассмотрим пример: нам требуется поменять тип колонки title на TEXT. Для этого нужно:

Изменить её column_definition в $columns
Выполнить код: $P->changeOrModifycolumn('title');
(Аргументом здесь является ключ в $columns.)

Другой пример — нужно не только поменять тип колонки, но и переименовать её в name. В этом случае последовательность действий такая:

Изменить column_definition в $columns
Выполнить код: $P->changeOrModifycolumn('title', 'name');
Изменить ключ в $columns с title на name

Если требуется только переименовать колонку:

Выполнить код: $P->changeOrModifycolumn('title', 'name', true);
Третий аргумент включает работу в режиме RENAME column.
Изменить ключ в $columns с title на name

Вызвав changeOrModifycolumnsQL с теми же аргументами, можно получить текст запроса без выполнения.

Приведение к типу при получении данных

PHP при получении данных из MySQL, преобразует все значения, кроме NULL, в строки.

Можно настроить поля в $columns так, чтобы данные преобразовывались в значения нужного типа.

Это делается либо в явном виде с помощью ключа value_type, либо автоматически на основании column_definition (см. ниже).

value_type может принимать следующие значения:

'int'

Величина будет преобразована в целое число (intval()).

Такой value_type автоматически устанавливается полям, которые согласно column_definition имеют тип из семейства INTEGER или DECIMAL без дробной части.

'float'

Величина будет преобразована в число с плавающей точкой (floatval()).

Автоматически устанавливается полям, которые в column_definition имеют тип FLOAT, DOUBLE или DECIMAL с дробной частью.

'json'

Этот тип автоматически устанавливается колонкам, имеющий одноименный тип в column_definition и приводит к преобразованию JSON-строки в массив или скалярную величину.

'bool'

Величина будет преобразована в логическое значение — true или false. NULL, как и во всех других случаях, будет оставлен без изменений.

Этот тип преобразования устанавливается только вручную в явном виде.

'datetime'

Такое преобразование можно использовать для значений даты/времени. Из обычных строк они превратятся в экземпляры специального класса, производного от DateTime, который снабжен методом __toString(), благодаря чему, при надобности (например, при выводе через echo или склейке с другими строками), преобразуются в стандартную строку даты. При этом с ними можно работать как с обычными объектами DateTime — смещать по временным интервалам, выводить в указанном формате и т.п.:

Этот тип преобразования, как и 'bool', устанавливается только вручную.

Отмена преобразования

Если в конфигурации явно указать value_type равным false, преобразование типа выполняться не будет независимо от column_definition.

JOIN подчиненных таблиц с группировкой

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

Рассмотрим пример: для каждого товара нужно узнать сумму продаж.

Предположим, продажи хранятся в таблице order_items с колонками:

product_id — id товара
price — цена продажи
quantity — количество единиц
sold — был ли товар фактически продан

Конфигурацию класса нужно дополнить:

public $tables = [

    ...,

    "GROUPING LEFT JOIN order_items AS i ON i.product_id = p.id AND i.sold = 1"

    // Нужен именно LEFT JOIN, т.к. продаж товара может не быть

];

public $columns = [

    ...,

    "total_sales_cost" => [

        "type" => "[min,max]",

        "sql" => "SUM(i.price * i.quantity)"

    ]

];

Ключевое слово GROUPING указывает на необходимость группировки результата по уникальному идентификатору главной таблицы, которая будет включена в запрос механизмом ORM автоматически. (Оно не является синтаксической конструкцией MySQL и будет исключено из итогового текста запроса.)

С total_sales_cost можно обращаться как с обычным параметром, используя его при фильтрации и группировке:

// Товары, которых продано на миллион или более:

$query = [

    'where' => [ 'total_sales_cost' => [ 'min' => 1000000 ] ],

];

// 10 самых продаваемых товаров

$query = [

    'orderby' => '{*total_sales_cost*} DESC',

    'limit' => 10

];

Рассмотрим другой, немного более сложный случай: получение суммы покупок клиентов.

В этом случае связь главной таблицы — таблицы клиентов — с таблицей продаж не прямая, а через промежуточную таблицу заказов:

public $tables = [

    "FROM clients AS c",

    "GROUPING LEFT JOIN orders AS o ON o.client_id = o.id",

    "LEFT JOIN order_items AS i ON i.product_id = p.id AND i.sold = 1"

];

Здесь GROUPING указывается для таблицы orders, т.к. связь «один ко многим» начинается именно с неё.

Связанные сущности

Под связанной понимается сущность другого рода, на которую через уникальный идентификатор ссылается некоторое поле данной сущности.

Например, у каждого товара есть производитель, id которого хранится в поле manufacturer_id. Производителям соответствует свой собственный класс Manufacturers, также унаследованный от _List, где описывается вся логика работы с ними: набор полей, параметры поиска, пост-обработка данных и т.д.

Чтобы этой логикой пользоваться в классе товаров, нужно установить его связь с классом производителей. Это делается через соответствующее поле (в данном случае — manufacturer_id), которому в конфигурации устанавливается свойство related:

class Products extends _List {

    public $columns = array(

        ...

        'manufacturer_id' => array(

            'related' => array('manufacturer' => 'Manufacturers')

            // 'имя ключа' => 'класс' (объяснение см. далее по тексту)

        ),

    );

    ...

}

class Manufacturers extends _List {

    public $tables = array(

        "FROM manufacturers m",

    );

    public $columns = array(

        "id",

        "title",

        "country_id",

    );

    function processData($row) {

       $row['url'] = "/manufacturers/$row[id].html";

       return $row;

   }

    ...

}

Установление такой связи даёт две важных возможности.

Поиск по свойствам связанных сущностей

Среди параметров поиска могут быть относящиеся именно к производителям, а не только к самим товарам.

При передаче методу find() в составе $query['where'] они должны быть сгруппированы в подмассив manufacturer (имя подмассива указывается в конфигурации в качестве ключа в related — см. выше).

Например, включать в форму поиска поле для указания страны производителя нужно с атрибутом name="manufacturer[country_id]":

<form>

    Цена от <input name="price_final[min]">

         до <input name="price_final[max]">

    <input name="has_discount" type="checkbox"> скидка

    <br>

    Название (начинается с) <input name="title">

    <br>

    Страна производства:

    <select name="manufacturer[country_id]">

        <option value="1">Россия</option>

        <option value="2">США</option>

        <option value="3">Германия</option>

    </select>

    <button>OK</button>

</form>

При этом сам вызов find() не меняется никак:

$query = array(

        'where' => $_GET,

        'orderby' => '[ord]',

        'limit' => [ 'p', ['N',20] ],

    );

$P = new Products;

$products = $P->find($query);

Единственное, что требуется — составить форму так, чтобы параметры поиска, относящиеся к производителю, приходили в подмассиве $_GET['manufacturer'].

Получение данных связанных сущностей

У каждой записи из $products автоматически появится подмассив manufacturer:

    ...

    [5] => Array

        (

            [id] => 5

            [price_final] => 35000

            [title] => Телевизор

            [has_discount] => 1

            [url] => /products/5.html

            [manufacturer] => Array

                (

                    [id] => 3

                    [title] => SONY

                    [country_id] => 7

                    [url] => /manufacturers/3.html

                )

        )

    [4] => Array

        (

            [id] => 4

            [price_final] => 1500

            [title] => Совок

            [has_discount] => 0

            [url] => /products/4.html

            [manufacturer] => Array

                (

                    [id] => 1

                    [title] => Полимербытхимпром

                    [country_id] => 1

                    [url] => /manufacturers/1.html

                )

        )

    ...

Добавление, изменение и удаление записей

write()

Для добавления записей и изменения их данных служит метод write(). В качестве аргументов он принимает массив полей записи и её идентификатор:

$P = new Products;

$P->write($_POST, $_GET['id']); // данные пришли из формы со страницы вида ?id=...

Если идентификатор не указывать, будет добавлена новая запись, а в ответ возращен ее идентификатор:

$P = new Products;

$new_id = $P->write($_POST);

При записи данные экранируются (используется mysql_write_row()), однако никаких проверок метод в себя не включает. Для этого рекомендуется использовать специальный инструмент для проверки правильности заполнения веб-форм.

write() может работать также в режимах DUPLICATE, IGNORE и REPLACE. Использование аналогично mysql_write_row(), за исключением того, что не требуется передавать имя таблицы.

Если таблица имеет уникальные ключи помимо первичного, для вставки данных в режиме DUPLICATE можно использовать метод insertOnDuplicateKeyUpdateAndReturnId(), который позволяет получить значение автоинкрементного поля для затронутой строки, будь то вновь вставленная или обновленная существующая:

$product_id = $P->insertOnDuplicateKeyUpdateAndReturnId($data, $unique_keys);

delete()

Метод delete() в качестве аргумента принимает уникальный идентификатор (автоматически экранируется) и просто удаляет соответствующую запись из таблицы, возвращая TRUE в случае успеха:

$id = ...;

$P = new Products;

$P->delete($id);

Дополнительные сведения и возможности

В основе данной библиотеки лежит подход к построению списков, сущность которого заключается в следующем: сначала из БД с учетом условий, сортировки и LIMIT извлекаются уникальные идентификаторы строк, после чего для этих строк запрашиваются остальные данные. Обоснованию и разъяснению этого подхода посвящена отдельная статья.

1. ▲ В классической реализации объектно-реляционного отображения каждой строке базы данных соответствует экземпляр объекта. Предлагаемая реализация не является классической: каждой строке здесь соответствует просто ассоциативный массив данных.

2. ▲ Используется функция mysql_escape().

3. ▲ Каждое из условий заключается в круглые скобки, чтобы ограничить действие оператора OR, если таковой встретится в выражении. То же самое касается произвольных условий (см. соответствующий раздел).

4. ▲ Следует отметить, что в конфигурации поля title отсутствует ключ sql. В таких случаях в качестве SQL-выражения используется непосредственно имя параметра.

5. ▲ Нумерация страниц начинается с единицы.

6. ▲ Если переменная для записи общего количества строк передана, будет выполнен отдельный запрос вида SELECT COUNT(*). Вопреки распространенной практике, такой вариант обладает более высокой производительностью, чем использование SQL_CALC_FOUND_ROWS. Подробнее см. http://sqlinfo.ru/forum/viewtopic.php?pid=38337

7. ▲ Если GET-параметр сортировки не соответствует ни одному из ключей массива $columns, он будет просто проигнорирован.

8. ▲ Конфигурация в примере имеет полную форму записи. Можно использовать также сокращенные формы:

public $columns = array(

    // все нижеуказанные варианты записи равнозначны

    'column' => [ // полная запись

        'sql' => 'table.column',

    ],

    'column' => 'table.column',

    'table.column',

    'column', // если среди всех задействованных таблиц нет колонок с одинаковыми именами,

              // указывать таблицу в явном виде необязательно

    ...

);

9. ▲ Метод find(), собственно говоря, состоит из вызова findIds() и getList().

10. ▲ Из-за этой возможности важно проверять пользовательские данные в случае, если они передаются методу напрямую. Например, для $P->getList($_GET['ids']) важно убедиться, что в GET-запросе передается именно массив чисел, а не строка, иначе возможна SQL-инъекция.

PHP: инструмент для проверки правильности заполнения веб-форм

Fri, 09 Aug 2013 19:14:10 +0400

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

Средство реализовано в виде функции, которая в качестве аргументов принимает массив с настройками проверок и массивы с данными запросов (обычно $_GET или $_POST), а в результате работы возвращает одномерный массив строк с сообщениями об ошибках. Код функции можно скачать здесь.

Каждый элемент массива с настройками соответствует ключу запроса (читай полю формы), и в нём перечисляются инструкции, по которым следует выполнять проверки.

Базовые проверки

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

<form>

    Получатель* <input name="fio">

    Адрес* <input name="address">

    Почтовый индекс* <input name="postcode"> 

    Вес отправления, кг* <input name="weight">

    Телефон <input name="phone">

    E-mail <input name="email">

    <button>Отправить</button>

</form>

Вот как будет выглядеть код для выполнения проверки:

$check_cfg = array(

        'fio' => 'Укажите получателя отправления.',

        'address' => array(

                '*' => 'Укажите адрес.',

            ),

        'postcode' => array(

                '*' => 'Укажите почтовый индекс места назначения.',

                '/\d{6}/' => 'Почтовый индекс должен состоять из шести цифр.',

            ),

        'weight' => array(

                '*' => 'Укажите примерный вес отправления.',

                '>= 0.2' => 'Минимальный регистрируемый вес отправления — 0.2 кг',

                '< 10' => 'Отправления тяжелее 10 кг не принимаются.',

            ),

        'email' => array(

                '/^\w[\w.-]*@(\w+\.)+\w{2,6}$/' => 'Адрес электронной почты введён некорректно.'

            ),

    );

$errors = check_form_errors($check_cfg, $_GET);

Как уже было сказано выше, каждому из полей формы соответствует набор инструкций, последовательно применяемых для выполнения проверок. Разберём каждую из них:

'*' => 'текст' - означает "проверить, что поле присутствует в запросе и заполнено (имеет ненулевую длину без учета пробелов по краям), в противном случае использовать 'текст' в качестве сообщения об ошибке". Для поля поля address эта проверка является единственной, и набор инструкция для него вместо

'address' => array(

        '*' => 'Укажите адрес.',

    )

можно записать в сокращенной форме: 'address' => 'Укажите адрес.', как это сделано для поля fio.

Инструкция вида '/.../' => 'текст' (ключ начинается и заканчивается слэшом) приводит к проверке поля регулярным выражением, содержащимся в ключе, в случае несовпадения с которым 'текст' будет использован в качестве сообщения об ошибке. В регулярном выражении можно использовать модификаторы, поместив их после закрывающего слэша.

Инструкции, где в ключе сначала идёт знак какого-либо неравенства, обрабатываются буквально так: «применить неравенство точно в указанном виде, подставив слева значение поля; если неравенство неверно — использовать текст в качестве сообщения об ошибке»¹.

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

Важно отметить, что все инструкции, кроме '*', выполняются только когда поле заполнено³. Поэтому, если отправить вышеуказанную форму, не заполнив ни одно поле, то, например, для почтового индекса и для веса сработают только первые из сообщений об ошибке, а для email ошибок вообще не будет.

Проверки с помощью сторонних функций

Проверки можно проводить и с помощью функций. Такие проверки могут быть двух типов.

Первый тип реализуется на основе функций, возвращаещих в результате работы логическую величину (TRUE или FALSE). В случае FALSE считается, что проверка не пройдена, и задействуется сообщение об ошибке.

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

Рассмотрим оба этих типа на примерах.

Предположим, решено проверять также номер телефона, но использовать для этого одно регулярное выражение неудобно, и лучше написать для проверки специальную функцию — скажем, validate_phone() — которая в качестве аргумента принимает номер телефона, а в ответ возвращает, правильный телефон или нет. Вот как будут выглядеть инструкции для поля phone в таком случае:

'phone' => array(

        'validate_phone()' => 'Номер телефона указан некорректно. Проверьте правильность написания.'

    );

При такой форме записи функции в качестве единственного аргумента передаётся значение соответствующего поля.

Функции можно передать и дополнительные аргументы. В таком случае запись инструкции немного усложнится:

'phone' => array(

        'validate_phone()' => array(

                'text' => 'Номер телефона указан некорректно. Проверьте правильность написания.',

                'args' => array('{*value*}', '495', $some_var),

            )

    )

Вообще говоря, полная запись любой инструкции включает в себя элемент 'text'. Например, проверка на заполнение поля fio в развернутом виде выглядит так:

'fio' => array(

        '*' => array(

                'text' => 'Укажите получателя отправления.'

            ),

    )

Если инструкция записана в таком, развернутом, виде, и элемент 'text' в ней отсутствует, проверка не приводит к регстрации ошибки ни в каком случае, независимо от своего результата. (Это свойство важно для некоторых случаев, речь о которых пойдет далее).

{*value*} — специальная метка, вместо которой будет подставлено значение поля. Её можно использовать и в текстах ошибок (это касается любых проверок, не только на основе функций). К примеру:

'email' => array(

        '/^\w[\w.-]*@(\w+\.)+\w{2,6}$/' => 'Введённый адрес e-mail — {*value*} — некорректен.'

    )

Инструкции, включающие второй тип проверок, сходны по виду и отличаются лишь наличием знака '+' перед именем функции.

Допустим, для проверки строки адреса стали использовать функцию find_address_errors(), которая в данной ей адресной строке ищет разнообразные ошибки и возвращает их в виде строки или списка (массива строк). Инструкции для поля address в этом случае станут выглядеть так:

'address' => array(

        '*' => 'Укажите адрес.', // Эта проверка остается без изменений

        '+find_address_errors()' => array(), // тексты ошибок находятся в коде функции

    )

Дополнительные аргументы, при необходимости, следует передавать так же, как и для первого типа инструкций.

Альтернативный вариант провести проверку второго типа — определить функцию прямо тут же:

'address' => array(

        '*' => 'Укажите адрес.', 

        function($query, $field_name) {

            // Этой функции передается весь массив с данными запроса ($_GET или $_POST)

            // а также название поля, для которого идет проверка.

            $value = $query[$field_name]; // Так можно получить значение поля

            ...

            // В случае обнаружения ошибок нужно вернуть их тексты

            // в виде строки или массива строк

        }

    )

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

Вложенные проверки

Бывают случаи, когда содержимое одного поля влияет на требования, предъявляемые к какому-то другому полю. Рассмотрим такую ситуацию на примере.

Скажем, при вводе параметров почтового отправления пользователям по желанию предоставляется возможность где-то зарегистрироваться. Изъявить такое желание можно, заполнив необязательное поле для пароля (<input name="password" ...>), при этом в качестве логина будет использован email; если пароль будет указан, а email — нет, это следует воспринимать как ошибку.

Это вносит в логику проверки некоторые изменения. Набор обязательных полей нужно в общем случае оставить неизменным, но если заполнено поле password — провести некоторые дополнительные проверки. Вот как в таком случае будут выглядеть инструкции для поля password:

'password' => array(

        '*' => array(

                '>>' => array(

                        'email' => 'Для регистрации введите адрес e-mail. (Если не хотите регистрироваться — просто оставьте поле "Пароль" пустым.)',

                    )

            ),

    )

Рассмотрим этот код подробнее.

Корневая инструкция представляет собой обычную проверку на заполненность. Однако она записана в развернутом виде и при этом элемент 'text' у этой инструкции отсутствует. Поэтому если эта проверка и потерпит неудачу (как это случится при отправке пустого пароля), никакой ошибки все равно зарегистрировано не будет.

Зачем же вообще тогда нужна такая инструкция? Ради элемента '>>'. Он представляет собой обычный список инструкций (и в него можно включать любые поля), которые выполняются только в том случае, если соответствующая корневая проверка пройдёт успешно (то есть, этот список является антагонистом ошибки). Буквально происходит следующее: те же самые поля независимо проверяются дополнительно с использованием массива '>>' в качестве набора инструкций, а выявленные ошибки дописываются к уже имеющимся⁴.

Предположим теперь, что в случае ввода пароля нужно не только проверить email, но и установить ограничение на длину пароля. Например, чтобы он был не короче трёх символов.

Это ограничение легко выразить с помощью регулярного выражения: '/.{3,}/'. Иметь эту инструкцию корневой, однако, нельзя (это обязало бы вводить пароль). Выйти из положения можно, поместив её в компанию к вложенной проверке email:

'password' => array(

        '*' => array(

                '>>' => array(

                        'email' => 'Для регистрации введите адрес e-mail. ...',

                        'password' => array(

                                '/.{3,}/' => 'Пароль должен быть не короче трёх символов.',

                            ),

                    )

            )

    )

Получается, что среди вложенных инструкций для поля password есть таковые для него самого же. Чтобы не писать название поля повторно, есть специальный ключ '/^R/'. С его помощью ту же самую инструкцию можно записать так:

'password' => array(

        '*' => array(

                '>>' => array(

                        'email' => 'Для регистрации введите адрес e-mail. ...',

                        '^R' => array( // указывает на password

                                '/.{3,}/' => 'Пароль должен быть не короче трёх символов.',

                            ),

                    )

            )

    )

Проверка файлов

Для файловых полей используются те же самые проверки, что и для обычных, однако они применяются уже не к собственно содержимому поля, а к массиву $_FILES, поэтому инструкции для файловых полей должны иметь специальную структуру.

Рассмотрим в качестве примера следующую HTML-форму:

<form method="POST" enctype="multipart/form-data">

    ...

    <input type="file" name="photo">

    ...

</form>

Массив $_FILES для такой формы в случае успешной загрузки файла будет иметь примерно вот такой вид:

Array

(

    [photo] => Array

        (

            [name] => britney 100x100.jpg

            [type] => image/jpeg

            [tmp_name] => /tmp/php1AD.tmp

            [error] => 0

            [size] => 2752

        )

)

Предположим, нужно проверить, чтобы загруженный файл являлся изображением в формате JPEG или PNG и не превышал по размеру 1 Мб. Код для таких проверок будет выглядить следующим образом (инструкции поля weight приводятся для сравнения):

$check_cfg = array(

        'photo' => array(

                'name' => array(

                        '/\.(jpe?g|png)$/i' => 'Файл должен быть в формате JPEG или GIF.',

                        // Для такой проверки можно было использовать и type: 

                        // принципиальной разницы нет, 

                        // т.к. type генерируется сервером на основе расширения файла.

                    ),

                'size' => array(

                        '< ' . (1024 * 1024) => 'Файл слишком большой, максимум - 1 Мб.',

                    ),

            ),

        'weight' => array(

                '*' => 'Укажите примерный вес отправления.',

                '>= 0.2' => 'Минимальный регистрируемый вес отправления — 0.2 кг',

                '< 10' => 'Отправления тяжелее 10 кг не принимаются.',

            )

    );

$errors = check_form_errors($check_cfg, $_POST, $_FILES)

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

'photo' => array(

        '*' => 'Нужно загрузить файл.',

        'name' => array(

                '/\.(jpe?g|png)$/i' => 'Файл должен быть в формате JPEG или PNG.',

                // Для такой проверки можно было использовать и type 

                // принципиальной разницы нет, т.к. элемент type

                // генерируется сервером на основе расширения файла.

            ),

        'size' => array(

                '< ' . (1024 * 1024) => 'Файл {*name*} слишком большой, максимум - 1 Мб.',

                // Метка {*name*} заменится на исходное имя загруженного файла  

            ),

    )

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

'photo' => 'Нужно загрузить файл.'

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

Отдельного рассмотрения заслуживает детальная обработка ошибок состояния загрузки файла. Информация о состоянии загрузки содержится в элементе 'error' в виде числового кода. Набор этих кодов фиксирован и довольно невелик, поэтому в функцию включены стандартные сообщения об ошибках для некоторых из этих случаев:

UPLOAD_ERR_NO_FILE (4): "Не выбран файл для загрузки."
UPLOAD_ERR_INI_SIZE (1): "Размер файла {*name*} не должен превышать Vб" (где V = ini_get('upload_max_filesize'))
Остальные: "При загрузке файла {*name*} возникли технические проблемы (код ошибки: {*error*})."

Если сообщения, относящиеся к тем или иным ошибкам загрузки, требуется настроить, в инструкции проверок нужно включить массив 'error'⁵:

'photo' => array(

        'error' => array(

                UPLOAD_ERR_NO_FILE => 'Все-таки нужно загрузить файл.',

                UPLOAD_ERR_CANT_WRITE => 'Файл загрузить не получилось — наверное, на сервере кончилось место.',

                // Коды, для которых тексты сообщений об ошибках не указаны,

                // будут обработаны с использованием стандартных сообщений

            ),

        ...

    )

Если стандартные сообщения хочется использовать для всех ошибок загрузки, включая отсутствие файла, вместо инструкции '*' следует указать 'error' => TRUE.

Следует отметить, что если при загрузке файла возникли какие-либо сбои (код ошибки отличается от UPLOAD_ERR_OK), никакие инструкции, кроме собственно проверки состояния загрузки ('*' и 'error'), не исполняются.

Проверка изображений

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

Array

(

    [0] => 450

    [1] => 675

    [2] => 2

    [3] => width="450" height="675"

    [bits] => 8

    [channels] => 3

    [mime] => image/jpeg

)

Предположим, нужно убедиться, что изображение нужного типа, и, кроме того, ограничить его максимальные размеры форматом 2048х1536. Также

Чтобы выполнить все эти проверки, нужно включить в инструкции для файлового поля специальный элемент — 'image':

'photo' => array(

        'image' => array(

                '*' => 'Файл "{*name*}" не является изображением или поврежден.',

                'mime' => array(

                        '/jpeg|png/' => 'Изображение должно быть в формате JPEG или PNG.'

                        // Нужно сказать, что getimagesize() устанавливает mime-type файла

                        // на основе анализа его содержимого (определяется верно даже 

                        // при неправильном расширении), поэтому для проверки типа изображения 

                        // лучше использовать результат работы getimagesize(), 

                        // а не содержимое $_FILES.

                    ),

                'width' => array(

                        '<= 2048' => 'Ширина изображения не должна превышать 2048 px.', 

                    ),

                'height' => array(

                        '<= 1536' => 'Высота изображения не должна превышать 1536 px.',

                    ),

            ),

    )

Инструкции по остальным свойствам (например, 'bits' или 'channels'), при необходимости, составляются по тем же принципам.

Ключи 'width' и 'height' используются в качестве псевдонимов для ключей 0 и 1 исходного массива от getimagesize().

Примечания

Дубликаты сообщений об ошибках перед завершением работы функции удаляются (с помощью array_unique).

Если содержимое поля формы является массивом, указанные проверки будут применены к каждому из его элементов.

Для генерации HTML-кода форм разработан специальный инструментарий.

1. ▲ Такие проверки лучше составлять, сначала продумав допустимый диапазон величин поля и выразив его в виде неравенства, а затем составить текст сообщения для случая, когда величина выходит за границы этого диапазона. Как правило, неравенство и текст должны противоречить друг другу (как это имеет место в примере: "<= 10" — "... тяжелее 10 кг ...", и т.п.).

2. ▲ C помощью функции trim().

3. ▲ При этом позиция, на которой среди инструкций находится '*', значения не имеет (то есть, её можно ставить и не первой, хотя это будет менее наглядно).

4. ▲ Никаких ограничений на вложенные инструкции по сравнению с корневыми нет. Уровень вложенности не ограничен.

5. ▲ Вообще говоря, инструкция '*' => 'текст' для файлового поля равносильна инструкции

'error' => array(
UPLOAD_ERR_NO_FILE => 'текст'
);

с той лишь разницей, что '*', в отличие от 'error', сработает и в том случае, если поле вообще отсутствует в форме (и — как следствие — отсутствует соответствующий элемент в массиве $_FILES).

PHP: критика перехода с оригинального API MySQL на mysqli и PDO

Fri, 29 Mar 2013 17:32:34 +0400

Оригинальный API MySQL (функции mysql_*() — например, mysql_query() и пр.) с версии PHP 5.5.0 объявлен устаревшим. Вместо него разработчики PHP рекомендуют использовать модуль mysqli или объекты данных PHP (PDO). Эти средства обладают расширенным по сравнению с традиционным API функционалом, но действительно ли они удобнее в повседневной практике?

mysqli

mysqli — "MySQL improved extension" ("улучшенный модуль MySQL") — прямой наследник оригинального API MySQL, обладающий более широкими возможностями. Чтобы почувствовать разницу, достаточно посмотреть на список его методов и сравнить с таковым оригинального модуля. Однако нужно отметить, что отличие в реальных возможностях на самом деле только одно: mysqli имеет возможность отправки множественных запросов ¹. Хотя иметь такую возможность и удобно, на практике её наличие ощутимой роли не играет².

Другими словами, разницы в реальных возможностях обычного и улучшенного модулей практически нет. Зато есть разница в интерфейсе. Рассмотрим, как в простейшем случае выглядит самая обычная операция — установление соединения с сервером MySQL и выполнение запроса:

// оригинальный модуль

mysql_connect('host', 'user', 'password');

mysql_query("SELECT 1");

// улучшенный модуль, процедурный интерфейс

$mysqli = mysqli_connect('host', 'user', 'password');

mysqli_query($mysqli, "SELECT 1");

// улучшенный модуль, объектный интерфейс

$mysqli = new mysqli($host, $user, $password);

$mysqli->query("SELECT 1");

Здесь важно заметить, что функция mysql_query() не требует передавать в явном виде указатель на соединение (хотя и позволяет это делать). В подавляющем большинстве случаев для работы требуется только одно соединение с MySQL, и, однажды установив его, вполне удобно и естественно просто вызывать mysql-функции, не ссылаясь на соединение в явном виде каждый раз.

Функция же mysqli_query(), напротив, требует передавать объект, указывающий на соединение. Этот объект потребуется во всех местах, где нужно будет делать запрос. Это означает, что в коде с локальной областью видимости — функциях и классах — придется либо заводить глобальную переменную, либо передавать этот объект явно.

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

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

PDO

PHP Data Object (Объекты данных PHP) — расширение языка, определяющее абстрактный интерфейс доступа к базам данных (это означает, что одни и те же методы PDO могут использоваться для разных СУБД).

На практике реально ощутимым отличием PDO от других интерфейсов к MySQL является возможность легко делать следующие две операции:

вставку в запрос параметров с экранированием
получение результата запроса в виде ассоциативного массива

Работа с MySQL, в основном, и заключается именно в этих двух вещах, поэтому многие разработчики останавливают свой выбор на PDO.

Однако есть один нюанс. Рассмотрим, как в самом простом случае средствами PDO выполняется запрос:

$DBH = new PDO('mysql:host=...;dbname=...', 'user', 'password'); // соединяемся с БД

$query = $DBH->prepare("SELECT 1"); // готовим запрос

$query->execute(); // выполняем запрос

Важно отметить, что для отправки запроса требуется вызывать не один метод, а два — prepare(), а затем execute(). На уровне механизма СУБД в данном случае задействуются т.н. prepared statements — специальный инструмент СУБД, позволяющий ускорить последовательное выполнение повторяющихся запросов, построенных по одному и тому же шаблону.

Вместе с тем, на практике идущие подряд однотипные запросы встречаются довольно редко. Напротив, обычно запросы разные, и это полностью нивелирует положительный эффект от предварительного разбора. Более того, в конечном итоге вместо одного запроса к MySQL делается два, в результате чего схема с prepare() и execute() оказывается даже медленнее обычного одиночного запроса.

PDO позволяет выполнить запрос и напрямую — для этого предназначен метод query(). Однако при использовании этого метода вставку в запрос параметров и их экранирование приходится проводить вручную, поэтому query() не пользуется популярностью и разработчики предпочитают связку из prepare() и execute() в любом случае, потому что это удобнее.

Следует также подчеркнуть, что при использовании PDO (как и в случае с mysqli) есть необходимость заводить объект, который в областях видимости функций и классов недоступен.

Резюмируя сказанное, нужно отметить, что по сравнению с другими модулями PDO предоставляет несколько более удобный функционал, однако реализация его выполнена неоптимально. Кроме того, высокий уровень абстракции интерфейса плохо сказывается на осведомлённости разработчиков о происходящем на стороне MySQL-сервера.

Что делать?

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

// если в глобальной области видимости есть переменная $mysqli,

// библиотека будет пользоваться инструментами mysqli,

// в противном случае - оригинального модуля MySQL

// включаем mysqli

$mysqli = mysqli_connect(...);

// простая отправка запроса

mysql_q("TRUNCATE sometable"); 

// получение результата скалярного (один столбец, одна строка) запроса

$now = mysql_getcell("SELECT NOW()");

// получение строки таблицы:

$row = mysql_getrow("

    SELECT * 

    FROM watches

    WHERE id = 1052

    ");

// получение столбца в виде одномерного массива:

$ids = mysql_getcolumn("

    SELECT id

    FROM watches

    WHERE mark = 'Edox' AND price > 5000

    ");

// получение записей таблицы с подстановкой в запрос параметров:

$sql = "

    SELECT *

    FROM watches

    WHERE mark = :mark AND price > :price

    ";

$params = array( 'mark' => 'Edox', 'price' => 5000 );

$data = mysql_gettable($sql, FALSE, $params); 

// подстановку можно делать во всех вышеперечисленных функциях

Подробнее о библиотеке можно прочитать в соответствующей статье.

1. ▲ Работу с транзакциями, хранимыми процедурами и прочим, заявленным в документации как отличия между модулями, на самом деле можно реализовывать с помощью собственно SQL-запросов: например, вместо $mysqli->commit() писать mysql_query("COMMIT"), и т.п.

2. ▲ Разница в производительности множественного запроса и соответствующего количества одиночных сводится к затратам на отправку запроса из PHP, которые по сравнению с затратами на собственно их выполнение механизмом СУБД как правило ничтожно малы. Кроме того, ситуация, когда запросы следуют подряд без необходимости промежуточной обработки результатов, является довольно редкой.

Архитектурная концепция программирования при работе со списками в веб-приложениях на основе PHP и MySQL

Thu, 28 Feb 2013 15:04:58 +0400

В статье излагается подход, позволяющий оптимизировать производительность запросов MySQL, а также облегчить написание кода на PHP с использованием специально разработанной для этого библиотеки.

Оптимизация запросов MySQL

Один из подходов к оптимизации запросов, используемых для получения данных списков, заключается в разбиении таких запросов на две части:

Получение списка идентификаторов.
Получение собственно данных.

Отчего так получается быстрее? Рассмотрим этот вопрос подробнее.

Как правило, списки составляются на основании каких-то условий (к примеру, показываются не все новости, а лишь несколько последних; не все товары, а только лежащие в определенном ценовом диапазоне и т.п.), при этом часто задействуются связи с другими сущностями (например, товары принадлежат к определенной категории, у новостей или статей может быть автор и др.). С точки зрения СУБД это означает, что требуется запрос типа JOIN с WHERE, ORDER BY (а часто - также GROUP BY) и LIMIT. Обычно такие запросы выполняются медленно и нередко становятся серьезной проблемой¹. В качестве примера возьмем запрос, используемый в CMS Wordpress:

SELECT * 

FROM wp_posts

LEFT JOIN wp_post2cat ON (wp_posts.ID = wp_post2cat.post_id)

LEFT JOIN wp_categories ON (wp_post2cat.category_id = wp_categories.cat_ID)

WHERE 1=1 

  AND (category_id = '1')

  AND post_date_gmt <= '2008-09-12 00:15:59'

  AND (post_status = 'publish')

  AND post_status != 'attachment'

GROUP BY wp_posts.ID

ORDER BY post_date DESC

LIMIT 9, 3;

Причина медленного его выполнения лежит в особенностях механизма работы MySQL и заключается в следующем. Сложность условий выборки не позволяет использовать для сортировки индексы, поэтому MySQL потребуется создать временную таблицу, содержащую все перечисленные в запросе колонки, которую затем отсортировать и выбрать указанное число записей. Поскольку такая временная таблица будет велика, эта операция будет происходить медленно (это усугубится еще сильнее, если временная таблица не поместится в оперативную память). Решающее значение здесь имеет именно общая длина колонок: чем длиннее строка таблицы, тем больше ресурсов потребуется на то, чтобы такие длинные строки переставить в нужном порядке.

Следует отметить также, что, по сравнению с общим количеством обрабатываемых записей конечное результирующее их число невелико. Получается, что б́ольшая часть работы по выборке содержимого ячеек и сортировке получившихся в результате длинных записей фактически делается впустую.

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

Вот как это будет выглядеть на практике при использовании языка PHP:

// 1.1. Уберем из запроса все колонки, кроме ID, а также лишние таблицы:

$sql = "

    SELECT wp_posts.ID 

    FROM wp_posts

    LEFT JOIN wp_post2cat ON (wp_posts.ID = wp_post2cat.post_id)

    WHERE (category_id = '1')

      AND post_date_gmt <= '2008-09-12 00:15:59'

      AND (post_status = 'publish')

      AND post_status != 'attachment'

    ORDER BY post_date DESC

    LIMIT 9, 3;

    ";

// 1.2. Теперь получим список идентификаторов:

$ids = array();

$result = mysql_query($sql);

while ( ($row = mysql_fetch_assoc($result) !== FALSE) 

    $ids[] = $row['ID'];

Теперь нужно получить непосредственно данные для этих трех записей, сохранив при этом порядок сортировки:

// 2.1. Получаем данные в неотсортированном виде:

$sql = "

    SELECT *

    FROM wp_posts

    LEFT JOIN wp_post2cat

    LEFT JOIN wp_categories

    WHERE wp_posts.ID IN (" . implode(",", $ids) . ")

    ";

$data_raw = array();

$result = mysql_query($sql);

while ( ($row = mysql_fetch_assoc($result) !== FALSE) 

    $data_raw[$row['ID']] = $row;

// 2.2. Восстанавливаем порядок сортировки:

$data_final = array();

foreach ($ids as $id)

    $data_final[$id] = $data_raw[$id];

Надо сказать, что выигрыш от такого разбиения достигается не всегда, и можно привести немало примеров, когда запросы выполняются быстро и в своем исходном виде. Но быстрые запросы выполнятся быстро в обоих случаях (дополнительная операция выборки по первичному ключу занимает очень мало времени), медленные же значительно ускорятся, поэтому использование разбиения запроса на две части в качестве единого подхода оправдано.

Библиотека для работы со списками

Описанный подход является одним из основных принципов, лежащих в основе универсальной библиотеки для работы со списками, которая реализует объектно-реляционное отображение. Библиотеке посвящена отдельная статья.

1. ▲ По данным курса по оптимизации производительности MySQL, запросы такого типа создают б́ольшую часть нагрузки на сервера MySQL в Рунете, а их оптимизация решает около 50% всех проблем производительности. См. также "Ботанический определитель" Григория Рубцова.

Конференция по управлению WhaleRider 2012, Москва 24-25 сентября 2012

Sun, 16 Sep 2012 22:41:50 +0400

Уважаемые читатели webew!

Сообщаем вам о ежегодной профессиональной конференции по управлению Whale Rider, которая пройдет 24 и 25 сентября в Москве.

Интернет-проекты сложны и требуют вовлечения большого количества разноплановых специалистов, которые мало что понимают в работе друг друга. Ключевая проблема отрасли - неумение работать слаженно, всем вместе. В качестве ключевой идеи конференции предлагается интеграция управленцев всех стадий жизненного цикла Интернет-продукта. Давайте рассмотрим весь жизненный цикл производства программного продукта, что одновременно и будет программой конференции Whale Rider 2012:

1. Что у нас в самом начале? Идея. И ничего больше. Может быть, капельку надежды. Отлично! Сюда мы приглашаем всех наших успешных бизнесменов и стартаперов со своими Success Story и "Ребята, мне повезло!". Мотивация и прочие моменты озарения, а также рассказы о том, "как сделать, чтобы и вы заработали свой миллион!"; Дальше можно осмысленно переходить к

2. Анализу. Почему заказчик получает в итоге не всегда то, что хочет? Как проверить идею и понять, а выстрелит ли проект? Какие фичи нужно делать, а какие нет? С чего начать? В секцию приглашены руководители отделов анализа и (!) заказчики.

3. Проектирование: как не увязнуть в дебрях размышлений и быстро выпустить продукт с нужным функционалом на рынок? Как показать инвесторам свою состоятельность и получить следующий транш на разработку? Как быстро проверить свои идеи, собрав на коленке прототип. Моделирование предметной области как способ синхронизации представления всех заинтересованных сторон о проблеме. Эта секция для руководителей отделов проектирования и юзабилити.

4. Разработка. Как пасти котов? Во сколько обойдутся ошибки управления разработкой вашему продукту? Что мир знает кроме Agile и Водопада? Как организовать миссию на Марс: что сделали менеджеры проекта Curiosity, чтобы провести удаленную (действительно удаленную) перепрошивку программного обеспечения? Приглашены технические директора, руководители отделов разработки, ведущие специалисты, тимлиды и архитекторы.

5. Тестирование и приемка. Вы, как заказчик, получили именно то, что хотели? На сцене руководители отделов тестирования и качества!

6. Эксплуатация управление сложными программно-аппаратными комплексами. Снижение стоимости владения: нужно ли бежать за модой и уходить "в облака"? Кому верить: маркетологу с ролексом или админу в свитере? На эти и другие вопросы ответят руководители поддержки и эксплуатации.

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

Выступить на секцию метауровня мы пригласили юристов, состоявшихся менеджеров продуктов и проектов, хороших продажников, директоров и гениальных маркетологов.

Все вместе мы будем обсуждать жизнь продукта от зарождения идеи, проектирования и разработки до экплуатации, прибыли и... выхода на IPO.

Читателям webew предоставляется скидка 10%. Для того, чтобы ею воспользоваться, введите SQLinfoCODE в заявку на формирование счета.

До встречи на конференции.

Highload++, Москва, 24-25 октября 2012

Sun, 15 Jul 2012 14:02:58 +0400

Объявлена конференция разработчиков высоконагруженных систем Highload++ 2012.

См. наш обзор Highload++ 2011 и спешите зарегистрироваться на официальном сайте

Пока Программа только формируется, немного о примерах докладов и собрании Программного комитета HL++. Компания Мамба, 250М хитов в сутки, вполне себе хайлоад, представит целую серию докладов:
+ специализированный поиск примерно в 100 раз быстрее Сфинкса;
+ персистентный производительный брокер очередей;
+ правильная система деплоя (заметьте - не просто система деплоя, а правильная!);
+ i18n на больших проектах;
+ использование comet для реалтайм счетчиков под реально большой нагрузкой.

Доклад Александра Короткова "Индексный поиск по регулярным выражениям".

Существует два основных подхода к выполнению поиска по регулярным выражениям с помощью индекса: "FREE indexing engine", основанный на выделении из регулярного выражения непрерывных фрагментов текста, и метод разработанный для Google Code Search, осуществляющий рекурсивный анализ составных частей регулярного выражения, с целью выявления его атрибутов. В целом же оба этих подхода используют инвертированные индексы на основе k-грам (подстрок исходной строки длиной k) и различаются методом извлечения k-грам из исходного выражения для последующего сканирования.

Данный доклад представляет новый метод извлечений k-грам из регулярного выражения, основанный не на анализе исходного регулярного выражения, а на преобразовании соответствующего конечного автомата. Предлагаемый подход позволяет осуществить более полное извлечение k-грам из регулярного выражения, что подтверждается примерами. Разработан патч к модулю pg_trgm СУБД PostgreSQL, реализующий данный подход.

Все из нас используют индексы в СУБД, но редко кто понимает, как они работают. Именно это понимание и отличает highload-разработчика от просто разработчика.

Алексей Тутубалин сделает доклад под кодовым названием "Используем современный процессор на 146%" про современное состояние параллельных вычислений. Приведем краткий конспект выступления:

+ Векторные операции (SIMD: MMX, SSE, AVX). SIMD расшифровывается как single instruction, multiple data - одиночный поток команд, множественный поток данных. Что умеет, типы данных, виды операций. Требования к программам и алгоритмам, выравнивание данных. Быстродействие формальное и реальное. Кто сделает SIMD-код?
+ Многоядерные процессоры, многопроцессорные конфигурации. Сложно думать параллельно, сложно отлаживать (невоспроизводимые ситуации), data races, расход ресурсов на синхронизацию, проблемы с процессорными кэшами если потоки работают с одними/близкими адресами в памяти. Типичное современное использование:
++ Несколько/много изолированных процессов
++ Несколько/много потоков (threads), обрабатывающих независимые запросы
++ Сложные многопоточные программы, сильно связанные внутри себя
++ Data-parallel программы: пилим (большие) данные на (независимые) куски и обрабатываем: map-Reduce (всех видов), сортировка, точки синхронизации/reduce понятны, не требуется синхронизация в случайный момент, да еще и по внешнему событию. Data races маловероятны. Программа выглядит последовательной, а вычислительно-интенсивные места используют все ядра/CPU.
+ Параллельные языки программирования:
++ ISPC: интересует CPU-only, двойная буферизация болезненна, нет желания таскать большой рантайм вне программы.
++ OpenCL: планируется/возможен перенос на GPU, рантайм не пугает, двойная буферизация не пугает.

РИТ++ 2012. Репортаж с места событий.

Mon, 16 Apr 2012 21:02:54 +0400

2-3 апреля 2012 года в Москве прошла ежегодная конференция "Российские интернет-технологии 2012" (РИТ++). Мероприятие впервые проходило в конференц-центре Digital October.

"Цифровой Октябрь" довольно сильно отличается от своего предшественника, поэтому поначалу было немножко непривычно.
Едят в "Цифровом Октябре" в специальной зоне питания под названием "Прогресс-бар". Существенным плюсом являлась возможность сидеть во время приема пищи (в отличие от "Инфопространства", где есть приходилось стоя). Это ведь самый настоящий бар, с длиннющей стойкой и стульями вдоль неё, а также с обычными столами и посадочными местами вокруг них. Так что усесться могло одновременно человек пятьдесят, не меньше. Имеются многочисленные экраны (включая один большой), по которым транслировались доклады.
Прогресс-бар весьма оригинально оформлен: стены украшают картины известных художников, гармонично дополненные образчиками современных технологий (ноутбук Apple, робот-собака и др.; в общем, всё, что символизирует прогресс).
Но, пожалуй, самой выдающейся особенностью является стеклянный участок пола, под которым уходит вниз лифтовая шахта (дна не видно). Этот участок находится как раз перед туалетом (а второй туалет далеко и не все про него знают), причем стекло сделано во всю ширину коридора и обойти его нельзя - чтобы попасть в туалет, нужно непременно ступить на стеклянную поверхность и сделать несколько шагов над инфернальной бездной (шахта подсвечена красными лампами). После такой прогулки, например, людям с боязнью высоты идти в туалет может оказаться уже поздно. А для тех, кто считает себя особо смелыми, персонал Прогресс-бара уже давно разработал программу веселого розыгрыша: датчик движения и проигрывание звука трескающегося стекла.. (правда, наверняка эта инициатива застрянет в руководстве).

Организаторы внедрили и другие нововведения.
Например, была целая свободная комната (мини-зал) со стульями для кулуарных обсуждений после докладов. Правда, участники, в основном, так и продолжали по старой привычке толочься в коридорах; благо, они в "Октябре" просторные.
Представители различных компаний, предлагающие услуги IT-сферы, расположились как-то более упорядоченно (среди них, кстати, хотелось бы отметить хостинг-провайдера 1stDEDIC, который предлагает выделенные сервера (не виртуальные, а настоящие, физические), начиная всего-то с 1800 руб.). Ну и неизменное массажное кресло в коридоре, которое так не хочется покидать.

На два полных дня было запланировано более 60 докладов, проходивших в три потока.

Открывал конференцию интригующий доклад о корейской open-source базе данных - CUBRID.
В NHN, флагмане корейской IT-индустрии (компания занимается, в основном, играми; имеет в общей сложности несколько десятков тысяч серверов), однажды решили, что имеющиеся корпоративные СУБД, такие как MS SQL или Oracle, не удовлетворяют всем их нуждам и в то же время дорого стоят. Поэтому в 2006 году была начата разработка собственного NoSQL-хранилища, предназначенного для хранения миллионов строк и терабайтов данных.
Команде разработчиков, распределенной между Кореей, Китаем и Румынией, удалось реализовать задуманное, и теперь CUBRID активно внедряется в NHN, заменяя платные продукты и сохраняя для родной компании миллионы долларов ежегодно.
СУБД снабжена транзакциями, высокоустойчивыми механизмами репликации, собственной файловой системой и многим другим.

Если вы планируете разработать какой-то программный продукт не для сообщества, а с расчетом на продажу прав на него, без осведомленности об инструментах защиты своих прав придется туго. Михаил Радченко из Softpatent провел ликбез по патентованию интернет-разработок.
В Росии многие недооценивают обладание патентом. А опыт показывает, что патентование повышает цену программного продукта примерно на два порядка.
Другая распространенная ошибка - патентование уже после начала работы, когда уже потрачены силы и средства, однако выясняется, что такое технологическое решение уже запатентовано кем-то другим. Мировые лидеры, такие как Microsoft, Google, Apple или Facebook заблаговременно проводят исследование патентного поля и выделяют на подготовку документации для патентов немало ресурсов (численность соответствующих отделов составляет десятки человек), продукт выпускается только после подачи заявки на патент, которых вышеупомянутые компании имеют сотни и тысячи.
Также важно помнить, что при расчете на патентование нельзя разглашать никакую информацию о продукте третьим лицам (в частности, выкладывать исходные коды в открытый доступ), в противном случае в регистрации заявки на патент будет отказано.

Секция client-side как всегда находилась на острие технологий, представив очень интересные и технологически глубокие доклады.

Владимир Журавлёв из Evil Martians много рассказывал про оптимизацию работы с jQuery и дал несколько полезных советов:
- сокращайте каскад в селекторе (длинные селекторы только медленней)
- группируйте частые события (типа mousemove) с помощью debounce и throttle
- вставляйте элементы в DOM пакетно, а не по одному (при каждом изменении DOM-дерева происходит перерисовка страницы)
- кэшируйте выборки, чтобы не делать их заново лишний раз
- заменяйте прямую установку css-свойств на присвоение классов
- используйте цепочки методов
- много each? посмотрите в сторону quickEach - будет быстрее где-то на порядок.
Кстати. Во время ответов на вопросы выяснилось, что есть еще места, где активно используют IE6, одно из них - Украинская Рада.

Артемий Ломов держал речь о производительности CSS-селекторов.
Неочевидным, но весьма важным является то обстоятельство, что селекторы применяются справа налево (с конца, то есть). Например, чтобы применить стиль для селектора .menu a, браузер сначала найдет все теги <a>, потом для каждого из них поднимется по DOM-дереву, выясняя, можно ли найти родителя с классом "menu", и только после этого применит стиль. Именно из-за такого, восходящего, порядка проверки, например, селектор .link будет работать быстрее, чем .menu .link. Поэтому с точки зрения производительности выгодней использовать направленные имена классов, без каскада.
Впрочем, здесь нужно знать меру и все же отдавать должное семантике документа, не впадая в крайности типа .ordered-list вместо ol li.

Антон Немцев представил очень яркий и интересный доклад про 3D-эффекты с помощью CSS.
Да, да. 3D. Конечно, как обычно, в IE меньше 10 не работает, так что приходится заботиться о деградации. Но всё же совершенно реально и уже применяется на работающих проектах.
3D в CSS создается с помощью свойства transform, дополненного инструкциями по анимации - свойством transition.
transform предписывает применить к элементу некое пространственное преобразование - сдвиг вдоль координатной оси, поворот вокруг координатной оси и др., transition указывает, за какое время должно происходить преобразование (при отсутствии transition преобразование применяется сразу), а также некоторые другие его параметры.
С помощью этих средств можно создавать совершенно поразительные по виду страницы, где блоки поворачиваются, отъезжают вдаль от зрителя и вообще ведут себя гораздо более неожиданно, чем того ждешь от простого HTML в браузере. Примером может служить презентация Антона, сверстанная с использованием только HTML и CSS, а также сайты christianheilmann.com, 2012.beercamp.com, wannafun.ru, acko.net, CannyBill и др.

Тему 3D средствами CSS/Javascript продолжил Андрей Ситник из Evil Martians, продемонстрировав, что 3D может использоваться не только для красоты, но и для повышения комфорта пользователя, делая происходящее на экране более похожим на реальный мир засчет имитации физики.
Кстати, Андрей упомянутл о библиотеке Modernizr, которая позволяет быстро определить, поддерживает ли текущий браузер и ОС 3D-инструменты. А в jQuery для анимации свойства translate, поскольку оно не цифровое, требуется расширение TransformJS.
А еще в презентации Андрея есть простые примеры CSS-кода, реализующего анимацию.
CSS - не единственное средство создания трехмерной графики в браузерах. Активно развивается стандарт WebGL, реализующий передачу низкоуровневых OpenGL-комманд видеокарте напрямую из JavaScript на основе HTML-тэга <canvas>. Вот несколько примеров его работы: трехмерный просмотр графика функции от Google, вода, браузерная 3D-игра с роботами, обзор телефона.
Также разрабатывается стандарт WebCL, целью которого является предоставление возможности передачи команд не центральному процессору, а процессору видеокарты, в графических расчетах более производительному.
Следует отметить, что отрисовка трехмерной графики - процесс ресурсоемкий. На не очень новых ОС (например, Windows до семерки) для обработки 3D не включается аппаратное ускорение, поэтому работать будет медленно.

Александр Сидоров и Петр Волков из Яндекса делились богатым опытом работы с зараженными сайтами, рассказывали о путях, которые могут привести к заражению и о том, как это предотвратить.
Возможностей получить на своем сайте посторонний код существует немало: от украденных FTP-паролей до уязвимостей в CMS и в программном коде самого сайта. Но, пожалуй, два самых неожиданных места - это недобросовестные партнерские программы (на сайт устанавливается код, например, рекламной сети, который занимается рассылкой приглашений на страницу с эксплойтом; всегда проверяйте, с кем имеете дело!) и зараженные сервера на хостинге.
Вирусы бывают очень хитры (например, не показываются залогиненным администраторам; показываются неравномерно, не давая воспроизводимости; показываются определенному диапазону ip-адресов и др.).
Наиболее распространенные площадки для работы вирусов - китайские, индийские и польские сайты (.cn, .in, .pl).

Завершали конференцию блиц-доклады (легкие пятиминутные выступления без дискуссии).

РИТ++ по-прежнему остается одним из главных отраслевых мероприятий, позволяя быть в курсе событий, творящихся в сфере интернет-технологий.

Вышла стабильная версия MariaDB 5.3.5

Thu, 01 Mar 2012 02:09:52 +0400

Вышла MariaDB 5.3.5 - первая стабильная версия в ветке 5.3.

Среди изменений:
* Оптимизация подзапросов, которая наконец делает подзапросы пригодными к использованию. Оптимизатор сам при необходимости переделывает подзапросы в JOIN.
* Изменения оптимизатора:
1. Hash join,
2. Batched Key Access
3. оптимизация использования индекса для range-запросов,
4. проверка части условий where при обращении к индексу,
* Включен плагин HandlerSocket, реализующий NoSQL доступ к базе данных.
* Групповой коммит в XtraDB</a> при включенном бинарном журнале.
* Улучшения производительности в Windows.

MariaDB доступна на сайте Ask Monty.

РИТ++, Москва, 2-3 апреля 2012

Wed, 29 Feb 2012 17:35:27 +0400

2 и 3 апреля в Москве пройдет конференция «Российские Интернет технологии» (РИТ++ 2012) — профессиональная конференция "от разработчиков для разработчиков". Ежегодно на РИТ++ встречаются лучшие эксперты крупнейших российских и международных компаний, разработчики браузеров и баз данных, языков программирования и веб-серверов, тимлиды и ведущие разработчики! В общем, все те, кто своими руками ежедневно ДЕЛАЕТ интернет.

Конференция будет сфокусирована на новом - новых технологиях, новых методах масштабирования, новых подходах к верстке мобильных сайтов, на всем перспективном, неожиданном и необычном. В этом году мероприятие охватит следующие направления:

+ Системное администрирование: операционные системы, сети, дата-центры, SaaS, безопасность, облака;
+ Базы данных: производительность и оптимизация, NoSQL, отказоусточивость и масштабируемость;
+ Технологии будущего (мы еще не знаем, что будет представлено в этом году);
+ Управление проектами: методологии, инструменты, командообразование, мотивация;
+ Качество: управление качеством, функциональное и нагрузочное тестирование;
+ Клиентское программирование: в этом году мы планируем встречу разработчиков веб-браузеров! А также JavaSocript, HTML5, RichMedia и мобильные приложения;
+ Серверное программирование: Perl, C/C++, PHP, Ruby, Python, Java.

На РИТ++ 2012 выступит Ян Плоскер, разработчик масштабируемой, отказоустойчивой распределенной базы данных Riak. Это не просто "еще одна NoSQL", а действительно новое решение. Только взгляните:
+ Теперь вам не нужно беспокоиться о единой точке отказа, т.к. в Riak нет master-node.
+ Забудьте про надежность оборудования! Вы можете лишиться нескольких нод кластера, но по-прежнему сможете получить свои данные.
+ Идеально подходит для всех web-приложений: как интенсивно пишущим, так и активно считывающим данные из базы данных.
+ Забудьте про планирование свободного места. Просто закажите еще серверов, подключите их к кластеру и тут же получите дополнительно пространство для новых данных.

Зарегистрироваться на конференцию можно на официальном сайте конференции.
Стоимость участия возрастает с приближением конференции.

Оптимизация запросов MySQL с использованием пользовательских переменных

Thu, 24 Nov 2011 03:13:45 +0400

Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.

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

Работа с индексами. Таблица, в который нет индексов, представляет собой беспорядочный набор строк, и для поиска нужной записи, допустим по id, необходимо проверить все ее строки на совпадение с искомым значением, для этого нужно просканировать всю таблицу от начала до конца. Это может занять много времени и будет исключительно неэффективно, особенно если таблица содержит только несколько записей, удовлетворяющих условию поиска.
В качестве примера рассмотрим таблицу, содержащую подведомственные рассматриваемому интернет-провайдеру организации. В данном контексте в таблице присутствует два поля – id организации (org_id) и название организации (org_name).

Допустим, мы добавили индекс на поле org_id (см. Рис. 1 ). Индекс содержит запись о каждой строке из таблицы, и записи индекса отсортированы по значению org_id. Теперь вместо сканирования всех записей в таблице мы можем воспользоваться индексом. Предположим, что требуется найти строку, содержащую запись об организации (Институт автоматики и электрометрии СО РАН), у которой уникальный идентификатор (org_id) равен 2. Сканирование по индексу возвращает одну строку. Значения в индексе отсортированы по возрастанию, поэтому достижении следующего значения (с org_id равным 3) можно завершать сканирование: после 3 мы уже не найдем нужных значений. В случае, если искомые значения находятся где-то посередине таблицы, с помощью специальных алгоритмов (например, методом бинарного поиска) можно перейти к нужной строке без длительного линейного сканирования таблицы.

Рис. 1. Взаимодействие с таблицей, с использованием индекса

В целом, большинство запросов можно оптимизировать, если правильно создать нужные индексы в таблице и построить запрос так, чтобы они эффективно использовались. Однако существуют такие запросы, скорости выполнения которых отнюдь не помогают индексы - например, в случае, когда по индексу выбирается больше чем около 1/10 всех записей в таблице, оптимизатор предпочтет FTS (Full Table Scan) вместо использования индекса, поскольку последовательное чтение с диска происходит быстрее, чем читать из разных частей диска (передвижение головки по диску — seek — это “дорогая” операция). Оптимизатор можно “заставить” использовать индекс, используя опцию FORCE INDEX, но это обычно не даёт выигрыша в скорости. Также таблицы могут быть такого большого размера, что создание индекса будет непрактичным с точки зрения занимаемого объема или длительности выполнения операции. Кроме того, за удобство использования индексов приходится определенным образом “расплачиваться”, у индексов есть свои недостатки. В большинстве своем они незначительны, но о них стоит знать.

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

Во-вторых, индексный файл занимает определенное место на диске (нередки случаи, когда индексы занимают больше места, чем сами данные). При создании большого количества индексов, размер такого индексного файла может быстро достичь максимального размера. Это может стать причиной достижения предельного размера таблицами быстрее, чем это было бы без использования индексов.

Для таблиц типа MyISAM излишнее индексирование таблиц может привести к достижению индексным файлом его максимального размера быстрее, чем файлом данных ( проблему можно решить с помощью PARTITIONING).
Таблицы типа BDB хранят данные и индексы в одном файле. Это, безусловно, является причиной более быстрого достижения максимального размера табличным файлом.
Таблицы типа InnoDB размещаются в едином табличном пространстве. При добавлении индексов дисковое пространство, отведенное под табличное пространство, будет исчерпано быстрее.

Пользовательские переменные. MySQL поддерживает пользовательские переменные (далее в тексте ПП), начиная с версии 3.23.6. Переменным можно присваивать значения, и обращаться к ним позже - это можно также использовать, когда есть потребность сохранить результаты вычислений для использования в дальнейших запросах. Например, для того, чтобы найти изделия с минимальной ценой, можно выполнить следующие действия:
mysql> SELECT @min_price:=MIN(price) FROM shop;
mysql> SELECT * FROM shop WHERE price=@min_price;

Пользовательские переменные записываются как @var_name, и могут принимать значения целого (int), дробного (real) и строчного (string) типа. Присваивание переменной значения производится через оператор SET (SET @var1='RUS'), через оператор SELECT (SELECT 'RUS' INTO @var1;) или в ходе выполнения запроса через оператор “:=” (“=” трактуется как равенство) (@var1:=72).

Неинициализированная переменная принимает значение NULL.

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

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

Недостатки использования ПП.

Сложная переносимость на другие СУБД (механизм ПП служит определенной надстройкой над реляционной моделью баз данных в рамках СУБД MySQL). Впрочем, данный недостаток не очень критичен, поскольку на данный момент все крупные СУБД имеют свои отклонения от стандарта ANSI SQL.
Поведение пользовательских переменных будет зависеть от порядка выполнения сложного запроса, который может меняться оптимизатором MySQL (если не используется оператор STRAIGHT_JOIN).

Пример №1. Одной из важных задач в мониторинге сетевого трафика является фиксация пиков загрузки предоставляемых каналов связи от поставщиков интернета (см. Рис. 2).

Рис. 2. График, отображающий динамику загрузки канала

Система мониторинга сохраняет информацию о входящем и исходящем трафике целиком, и в частности, по каждому из каналов в отдельных таблицах. Тип таблицы – MyISAM.
Упрощенная форма таблицы такого типа:

t (временная метка)

src (количество отданных байт)

dst (количество принятых байт)

Для поиска максимального скачка входящего (также как и исходящего, но в этом случае идёт работа с полем src) трафика необходимо просканировать всю таблицу, при этом сравнивая значения поля dst, соответствующие меткам t_prev (временная метка на предыдущем шаге ) и t_curr (временная метка на текущем шаге). В этом и состоит основная сложность: в рамках реляционной модели невозможно запомнить предыдущее значение в процессе сканирования таблицы и использовать его напрямую. Его можно вычислить с помощью подзапроса
SELECT dst FROM t t2 WHERE t2.t<t1.t ORDER BY t2.t DESC LIMIT 1;
где t1.t – текущее значение временной метки), но такая конструкция сильно усложняет запрос, в общем случае сложность запроса с O(n) увеличивается до O(n²) (из-за того, что приходится для каждой временной метки вычислять предыдущую путём сканирования всей таблицы), что сильно сказывается на скорости выполнения запроса. В случае наличия в таблице уникального индекса на поле t, вычисление будет проводиться значительно быстрее, но это тогда, когда точно известно, что в таблице нет пропущенных временных меток (а такая идеальная ситуация практически не встречается), и предыдущая временная метка вычисляется просто вычитанием нужного интервала из текущей (по уникальному индексу выборка проходит очень быстро). В общем же случае значение временной метки на предыдущем шаге приходится вычислять подзапросом, основанным не на строгом равенстве, а на нестрогом, используя сортировку, и такой запрос, естественно, работает значительно дольше. В реляционном варианте в подзапросе для более быстрой выборки данных требуется индекс на поле t, а во внешнем запросе идёт работа с полем dst, поэтому в данном случае в таблице создан составной индекс t_dst на поля (t, dst).

Реляционный вариант запроса:SELECT MAX(t1.dst-(SELECT dst FROM t t2 WHERE t2.t<t1.t ORDER BY t2.t DESC LIMIT 1)) FROM t t1;

Как видно из запроса, приходится приходить по таблице n + 1 раз. пользовательские переменные позволяют реализовать такой запрос за один проход по таблице. для того чтобы запрос, который осуществляет один проход по таблице сработал корректно, необходимо, чтобы данные выбирались в порядке возрастания временной метки. этого можно достичь следующими путями.

Отсортировать данные в таблице (если это требуется) запросом ALTER TABLE `t` ORDER BY `t` (для таблиц типа MyISAM – рабочее решение) до выполнения запроса. В случае, если данные были вставлены последовательно, но из таблицы было удалено несколько записей, нужно дефрагментировать таблицу запросом OPTIMIZE TABLE `t`. Поскольку данные отсортированы заранее, то в запросе применяется инструкция IGNORE INDEX(t_dst), чтобы данные выбирались не по индексу, а последовательно.
Наличие составного индекса на выбираемые (используемые в WHERE/ORDER BY/GROUP BY) поля позволяет выбирать по нему (по индексу) данные – то есть в порядке возрастания выбираемого поля. В данном случае наличие составного индекса t_dst на поля (t,dst) обеспечивает выборку данных в порядке возрастания метки t. Для того чтобы оптимизатор обязательно использовал индекс при выборке, нужно применить инструкцию FORCE INDEX(t_dst).
Выбирать данные не из таблицы t, а из созданной из нее динамической выборки, отсортированной по полю t по возрастанию (SELECT * FROM `t` ORDER BY `t`).

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

Запрос, работающий с таблицей, где данные расположены в нужном порядке.

SET @data=NULL, @next_data=NULL, @max_value=0;

SELECT @next_data:=`dst` `nextdata`,IF (@next_data- @data>@max_value, @max_value:=@next_data-@data, @max_value),  @data:=dst FROM `t` IGNORE INDEX(t_dst);

SELECT @max_value;

Запрос, выбирающий данные в нужном порядке по индексу:

SET @data=NULL, @next_data=NULL, @max_value=0;

SELECT @next_data:=`dst` `nextdata`,IF (@next_data- @data>@max_value, @max_value:=@next_data-@data, @max_value),  @data:=dst FROM `t` FORCE INDEX(t_dst);

SELECT @max_value;

Запрос, сортирующий данные в процессе выборки:

SET @data=NULL, @next_data=NULL, @max_value=0;

SELECT @next_data:=`dst` `nextdata`, IF (@next_data - @data > @max_value, @max_value:=@next_data-@data,  @max_value),  @data:=dst FROM (SELECT * FROM `t` ORDER BY t) t1;

SELECT @max_value;

В таблице 1 приведены длительности выполнения запросов (при разном количестве строк в таблице). Количество строк в таблице определяется длительностью интервала. В данном случае рассматриваются интервалы длительностью в одну минуту.

Период	Количество строк	Реляционный вариант запроса	Запрос с ПП (последовательная выборка)	Запрос с ПП (сортировка в процессе выполнения)	Запрос с ПП (сортировка осуществляется за счет выборки по индексу)
1 день	1,440	2,67 сек	0.00 сек	0.00 сек	0.00 сек
1 неделя	10,080	2 мин 11 сек	0.00 сек	0.01 сек	0.02 сек
1 месяц	43,200	40 мин 1 сек	0.02 сек	0.04 сек	0.07 сек
1 год	525,600	Более трёх суток	0.54 сек	0.68 сек	0.94 сек

Таблица 1. Измерения длительностей выполнения запросов из примера №1.

Результаты измерений длительностей выполнения запросов подтверждают то, что реляционный вариант запроса в данном случае абсолютно неприменим, а все варианты запросов с пользовательскими переменными выполняются быстрее чем за секунду, что в большинстве случаев приемлемо.

Пример №2. Для анализа загрузки канала регулярно приходится оценивать загрузку за определенные временные промежутки (по несколько секунд, несколько минут). В данном случае выбран интервал с длительностью 5 секунд. Структура таблицы, из которой выбираются данные - такая же, как в примере №1, временная метка t должна иметь тип TIMESTAMP.

Реляционным запросом такая выборка реализуется через группировку с последующей сортировкой результатов: SELECT `t`-INTERVAL(UNIX_TIMESTAMP(`t`)%5) SECOND AS s5,SUM(`dst`) AS `d` FROM `t` GROUP BY s5 ORDER BY `t`

Помимо полного прохода по таблице в данном запросе еще реализуется группировка и сортировка результатa.
Тот же запрос можно реализовать через пользовательские переменные с меньшей нагрузкой за счет отсутствия явной группировки, и, следовательно, сортировки (при условии, что в таблице нет пропущенных временных меток).

Запрос, работающий с таблицей, где данные расположены в нужном порядке:

SET  @c:=0;

SELECT  `t`, `dst`  FROM ( SELECT  `t`, IF(UNIX_TIMESTAMP(`t`) % 5, @c := @c+`dst`, @c := `dst`) AS `dst`, IF ((UNIX_TIMESTAMP(`t`) + 1) % 5, 1,0) AS  `mark`  FROM `t` IGNORE INDEX(`t_dst`)) t1  WHERE  mark = 0;

Запрос, выбирающий данные в нужном порядке по индексу:

SET  @c:=0;

SELECT  `t`, `dst`  FROM ( SELECT  `t`, IF(UNIX_TIMESTAMP(`t`) % 5, @c := @c+`dst`, @c := `dst`) AS `dst`, IF ((UNIX_TIMESTAMP(`t`) + 1) % 5, 1,0) AS  `mark`  FROM `t` FORCE INDEX(`t_dst`)) t1  WHERE  mark = 0;

Запрос, сортирующий данные в процессе выборки:

SET  @c:=0;

SELECT  `t`, `dst`  FROM ( SELECT  `t`, IF(UNIX_TIMESTAMP(`t`) % 5, @c := @c+`dst`, @c := `dst`) AS `dst`, IF ((UNIX_TIMESTAMP(`t`) + 1) % 5, 1,0) AS  `mark`  FROM ( SELECT * FROM `t` ORDER BY `t`) t1) t2  WHERE  mark = 0;

В рамках выполнения подзапроса сперва идёт суммирование в переменную @c, и в случае, если временная метка соответствует пятисекундному интервалу, то обнуляется счетчик и метке mark присваивается значение 1. Далее внешний запрос выбирает те строки, у которых mark равен 1, то есть искомые.

В таблице 2 приведены длительности выполнения запросов (при разном количестве строк в таблице).

Период	Количество строк	Реляционный вариант запроса	Запрос с ПП (последовательная выборка)	Запрос с ПП (сортировка в процессе выполнения)	Запрос с ПП (сортировка осуществляется за счет выборки по индексу)
1 день	86,400	0.11 сек	0.05 сек	0.1 сек	0.08 сек
1 неделя	604,800	0.86 сек	0.33 сек	0.73 сек	0.6 сек
1 месяц	2,592,000	33.72 сек	1.65 сек	3.62 сек	2.83 сек
1 сезон (3 месяца)	7,776,000	2 мин 45 сек	4,87 сек	10.46 сек	8.36 сек

Таблица 2. Измерения длительностей выполнения запросов из примера №2

Как и в первом примере, приведенные варианты запросов с использованием пользовательских переменных MySQL работают в несколько раз быстрее.

Пример №3. С точки зрения работы сети подведомственные организации описываются определенными техническими характеристиками, в частности, выделенными для организации диапазонами IP-адресов. Иногда возникает потребность вычленить самые крупные непрерывные блоки IP-адресов, выделенные для организации.
Таблица организаций и их сетевых диапазонов (nets) представлена следующим образом:

org_id
(id организации)

org_name
(название организации)

net
(адрес сети, 4 байта)

net
(маска сети, 4 байта)

В случае, если нужно выбрать самый крупный непрерывный сетевой диапазон у каждой организации, особых сложностей нет. Но если необходимо выбрать по два самых крупных сетевых диапазона – реляционный вариант запроса на выборку становится достаточно сложным – необходимо для каждого диапазона посчитать количество более крупных сетевых диапазонов, после отсеять те, которые меньше первых двух (подробнее см. здесь).

Вариант запроса в реляционной модели:

SELECT 

    t1.org_id,

    t1.org_name,  

    (SELECT 

         count(*) 

     FROM 

         `nets` t2 

     WHERE 

         t2.org_id = t1.org_id AND ((t2.mask<<32)+t2.net) < ((t1.mask<<32)+t1.net)

    ) c, 

    inet_ntoa(t1.net), 

    inet_ntoa(t1.mask)

FROM

    nets t1 

HAVING 

    c<2 

ORDER BY 

    org_id, mask;

С помощью пользовательских переменных можно в рамках одного прохода подсчитывать количество выведенных сетевых диапазонов и обнулять счетчик при смене организации. В случае, если счетчик достигает нужного значения (в данном случае 2), записи не выводятся. Саму таблицу перед использованием нужно отсортировать по размерам сетевых диапазонов в рамках организации.

Вариант запроса с пользовательскими переменными MySQL:
set @i=0, @p=0;
SELECT
t.org_id,
t.org_name,
inet_ntoa(t.net), inet_ntoa(t.mask)
FROM
( SELECT * FROM `nets` ORDER BY `org_id`, `mask` ) AS t
WHERE
( (if (@p=org_id, @i:=@i+1,(@i:=0) or (@p:=org_id))) and @i<2);

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

Пример №4. В предыдущих экспериментах ни разу не рассматривался вариант модификации структуры таблицы (в реальной жизни далеко не всегда ее можно или удобно менять). Однако при работе с темпоральными таблицами просто напрашивается решение сделать еще одну колонку, которая будет содержать предыдущее значение prev измеряемого параметра. Для наиболее высокой скорости поиска максимального перепада значении можно добавить поле, которая будет содержать разницу diff между текущим значением измерения d и предыдущим.

Рассмотрим вариант изменения структуры таблицы – добавление колонки prev. Исходная таблица с данными такова:

t (временная метка)

d (данные измерения)

Таблица не содержит индексов и первичного ключа – при наличии индекса на поле t или составного индекса на поля (t,d) реляционный вариант запроса работает значительно медленнее.

Вариант модификации в рамках реляционной модели БД:
CREATE TABLE `t_modifyed` SELECT t, (SELECT `d` FROM `t` `in` where `in`.t < `out`.`t` order by t desc limit 1 ) prev, d FROM `t` `out` ORDER BY `t`;

Вариант модификации с использованием пользовательских переменных: set @v = NULL; CREATE TABLE `t_moifyed` SELECT t, @v prev, @v:=d d FROM `t` ORDER BY `t`;

В таблице 3 приведены длительности выполнения запросов (при разном количестве строк в таблице).

Период	Количество строк	Реляционный вариант запроса	Запрос с ПП (последовательная выборка)	Запрос с ПП (сортировка в процессе выполнения)
1 день	1,440	0.35 сек	0.00 сек	0.00 сек
1 неделя	10,800	12.33 сек	0.00 сек	0.01 сек
1 месяц	43,200	3 мин 45 сек	0.10 сек	0.15 сек
1 год	525,600	более 5 часов	0.54 сек	0.96 сек

Таблица 3. Измерения длительностей выполнения запросов из примера №4.

Другие способы применения. Многие реляционные СУБД позволяют в ходе выполнения запроса использовать номер текущей строки вывода.

Oracle (переменная: rownum)
Microsoft SQL (функция ROW_NUMBER())
PostgreSQL (функция ROW_NUMBER())

В MySQL rownum можно корректно эмулировать только с помощью пользовательских переменных:
set @n:=0;
select @n:=@n+1 as rownum, t.* from t;
Строго говоря, в MySQL нет небходимости использовать rownum: для ограничения количества возвращаемых запросом строк существует инструкция LIMIT, но иногда может потребоваться.

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

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

Аналогичная возможность в других реляционных СУБД. Механизм, аналогичный механизму пользовательских переменных имеется почти во всех современных реляционных СУБД. В данном разделе приведены примеры для PostgreSQL и Microsoft SQL. В случае использования функций, приведенных ниже необходимо учитывать то, что при их создании не были предприняты никакие действия для того, чтобы строки выбирались из таблицы в нужном порядке (по возрастанию метки t ).

PostgreSQL: СУБД PostgreSQL не поддерживает возможность использовать пользовательские переменные в процессе выполнения запроса. Но начиная с версии 9.0 в PostgreSQL есть возможность создавать анонимные блоки кода. К сожалению, они не поддерживают формальных параметров и не возвращают значений. Однако есть возможность создать функцию в схеме pg_temp, что обеспечит автоматическое удаление функции из схемы по завершении сессии. Пример функции, вычисляющей максимальный перепад:
DROP FUNCTION IF EXISTS pg_temp.max_drop();
CREATE FUNCTION pg_temp.max_drop() returns int as $$
DECLARE
prev INTEGER; curr INTEGER; max_ INTEGER;
begin
max_ := 0; prev := 0;
FOR curr IN SELECT d FROM pogoda
LOOP
IF (curr - prev > max_) THEN max_ := curr - prev; END IF;
prev := curr;
END LOOP;
RETURN max_;
end
$$ lANGUAGE plpgsql;

Microsoft SQL: Основное отличие запроса от запроса с использованием ПП MySQL в том, что у переменной нужно задавать тип заранее.
DECLARE @diff int;
DECLARE @prev int;
set @diff = 0;
set @prev = 0;
select @diff = case when @diff> (d-@prev) then @diff else (d-@prev) end, @prev = d from npogoda;
select @diff;

Oracle: на момент написания этой статьи в языке Oracle SQL отсутствует возможность использовать пользовательские переменные - такая возможность имеется лишь в языке PL/SQL и таких расширениях, как SQLPLUS, Oracle XE, и. т. д.

Благодарности. Автор выражает благодарность за неоценимую помощь в процессе написания следующим людям:

Highload++ 2011. Репортаж с места событий.

Tue, 18 Oct 2011 14:20:47 +0400

3 и 4 октября 2011 года в Москве проходила пятая ежегодная конференция разработчиков высоконагруженных систем Highload++.

На два дня конференции было запланировано более 40 докладов, разбитых на два потока. Среди выступавших были представители мировых лидеров (Facebook, Microsoft, Google, Badoo) и флагманов отечественного сегмента отрасли (ВКонтакте, Одноклассники, Mail.ru и др.).

На этот раз стены «Инфопространства» вместили в себя более 700 человек. Эти внушительные цифры ощущались даже физически.
Из бытовых нововведений порадовал огромный экран в холле, который позволял лицезреть докладчика, не отрываясь от приема пищи и праздношатания, а также непрерывно функционирующую фуршетную линию, которая позволяла прием пищи практически не прекращать.

Ярослав Сергеев из Mamba рассказал об эволюции разработки веб-проекта. Особенно о той стадии, когда сил одного технического лидера, управляющего небольшой (до 10-12 человек) группой равноправных разработчиков, начинает не хватать, и необходимы качественные изменения в стркутуре девелоперского подразделения компании.
Чтобы масштабировать разработку, программистов требуется разбить на рабочие группы во главе со старшим разработчиком-тимлидом, каждая из которых занимается определенным направлением и привязывается к определенному product-менеджеру, который отвечает за выполнение поставленных перед группой задач (т.е. у каждого PM'а своя группа).
Важной составляющей успешного процесса также является выделение отдельной группы на support — именна она (а не разработчики) занимается исправлением ошибок после выпуска очередной версии на production (при спорах вмешивается технический директор). Это разгружает разработчиков, которые не отвлекаются от решения последующих задач и потому делают их в гораздо более предсказуемые сроки, что очень повышает удобство и успешность планирования. Костяк support-группы должны составлять люди с определенным складом характера, любящие такую работу (таких немного, и подобрать этот костяк непросто), но саппорт подходит и для обкатки новичков, ознакомления их с внутренней структурой системы.

Андрей Сас из Badoo похвастался мощностями, пригодными для успешной отправки 100 миллионов писем в день (97% доставка в Inbox, среднее время от события до доставки — 25 секунд).
Добиться таких выдающихся результатов удалось, спроектировав и построив мощную, но достаточно простую систему отправки писем, развернутую на двух географически распределенных кластерах из 10 машин, на разработку которой потребовалось 1.5 человеко-года.
Система работает асинхронно: есть отдельная очередь на генерацию писем и отдельная — на отправку. Состояние обеих очередей включено в мониторинг и отслеживается на предмет переполнений. Андрей утверждает, что грамотная организация мониторинга (включая сбор информации об открытии писем с помощью вставки в них изображений-маркеров с уникальным адресом) — один из ключевых факторов успеха, без которого невозможно организовать качественную работу сервиса.
Письма хранятся в виде физических файлов (управление ими осуществляется манипуляциями на уровне каталогов файловой системы). Поэтому самый главный hardware-ресурс — это диск (в текущей конфигурации используется RAID 1+0 из 4 SSD), загрузка процессора не превышает 2-3% в пике, памяти также хватает немного — 2-4 Гб. В качестве MTA используются Communigate Pro (быстрый) и Postfix (медленный, но гибкий, бывает нужен для определенных типов писем). Единственный секрет, который Андрей не стал раскрывать — как все-таки удается спастись от спам-фильтров.

Максим Лапшин выступил с докладом Высокая нагрузка на erlang-приложения: erlyvideo на гигабитном канале.
Видеостриминговый сервер erlyvideo позволяет одновременно обслуживать более 2000 пользователей с одного источника. Добиться такого результата Максиму удалось, призвав на помощь язык erlang, на освоение которого до уровня, необходимого для решения задачи, он потратил всего несколько дней.
Erlang был выбран в силу своих архитектурных особенностей, в частности очень хорошей (практически линейной) автоматической масштабируемости по ядрам процессора и возможности "горячей" отладки (можно внедриться прямо в работающий процесс, не приводя к заметному росту нагрузки).
Отмечатся также высокое качество работы сборщика мусора: утечек не было даже при многомесячной непрерывной работе сервера.

Domas Mituzas рассказывал, как в Facebook готовят MySQL.
При сверхвысоких нагрузках MySQL может давать сбои в самых неожиданных местах. В Facebook, где может происходить до 60 миллионов MySQL-запросов в секунду, об этом знают не понаслышке.
Возникшие проблемы команда из Facebook обычно решает самостоятельно, не дожидаясь исправления ошибок или новых релизов, и выпускает для MySQL собственные патчи. Среди целевых объектов патчей — оптимизация операций DROP TABLE и ALTER TABLE (online schema change), разнообразные детали функционирования InnoDB, работа с диском и многое другое.
Впрочем, Domas назвал несколько приемов, доступных и при использовании обычных версий MySQL. Напримрер, запуск нескольких MySQL-серверов на одной машине, а также плотное использование FORCE INDEX (чтобы избежать ненужного обращения к альтернативным индексам, которые все равно использоваться не будут).
Сейчас в Facebook используют MySQL версии 5.1, но переходить планируют сразу на 5.6.
Ссылка по теме: MySQL в Facebook.

Константин Осипов и Александр Календарев (Mail.ru) представили noSQL-хранилище Tarantool как альтернативу Redis. По производительности Tarantool находится примерно на том же уровне, что и конкурент (сотни тысяч операций чтения и записи в секунду), но имеет важные отличительные черты в архитектуре.
Tarantool является однопоточным сервером с точки зрения использования процессора. Это делает невозможным масштабирование по ядрам, однако на практике более важным оказываются такие следствия однопоточности, как отсутствие блокировок и конкуренции за системную шину, в результате чего ограничивающими факторами производительности являются пропускная способность памяти и сетевых интерфейсов, а не процессор (на рабочих системах загрузка процессора не превышает 10-20%).
Данные Tarantool хранятся в виде пространств (аналог таблиц в традиционных СУБД) с неограниченным количеством столбцов произвольных типов, в которых хранятся записи в т.н. кортежей, имеющих произвольную размерность и типы полей.
Помимо базовых команд, есть стандартный SQL-интерфейс, а также возможность писать хранимые процедуры на языке Lua, которые выполняются сервером атомарно (без переключения контекста процессора).
Tarantool используется в ряде крупных работающих систем (в т.ч. для хранения сессий Mail.ru: 40 млн. активных пользователей, 80 Гб данных, 2 мастера + 2 реплики, шардинг по user_id).
Официальная страница Tarantool: http://tarantool.org

Pconnect: граната в руках обезьяны — яркое выступление Сергея Аверина (Badoo Development) на тему того, как может навередить неумелое использование persistent-соединений.
Работа с постоянными соединениями имеет свои подводные камни, о которых в обычной ситуации даже не задумываешься. Подводят исправно служившие в обычной ситуации средства.
Например, зачастую средствами библиотеки нельзя понять, является ли переданное соединение новым или существующим, нет возможности управлять текущими открытыми соединениями, а иногда соединение вообще нельзя закрыть.
Протокол должен предусматривать закрытие соединения при ошибках синтаксиса синхронизации (в противном случае может появляться "полоса сбивки" — битые байты проигнорируются и ответ продолжит читаться, но со сдвигом на неизвестное число байт) и идентификацию запрашивающего клиента (т.к. одно и то же соединение может передаваться между разными клиентами, без таких проверок данные могут попасть не тому, кому они предназначались; например, так в Badoo однажды залогинили 10 000 пользователей не в свои аккаунты).

"Курочка по зёрнышку клюет" — так можно кратко охарактеризовать доклад Андрея Аксёнова о низкоуровневой оптимизации C/C++
Создатель сервера полнотекстового поиска sphinx делился маленькими секретами низкоуровневой оптимизации, которые могут дать большой результат ("1% я беру"): от учета тонких нюансов в работе процессора и памяти до замены switch на if и byte на int.
Эти небольшие оптимизации, сложенные воедино, могут давать ощутимый прирост производительности и делать системы действительно быстрее некуда.

Иван Авсеянко выступил с рассказом о column-oriented СУБД.
Хранение и обработка статистики зачастую требует работы со столь большими объемами данных (характерный пример — журнал посещаемости сайта с милионной посещаемостью), что традиционные СУБД не справляются. Специально для таких задач и предназначено семейство column-oriented СУБД, в которых ячейки данных при хранении группируются не по строкам, а по столбцам (где данные, вдобавок, еще и отсортированы).
Одна из ключевых особенностей таких СУБД — степень сжатия хранимых данных, которая у некоторых из них может достигать нескольких раз (данные, однако, обычно являются read-only, поэтому частые обновления нежелательны; скорость загрузки данных — важная характеристика при практической работе с СУБД)
Другая хитрость — предварительный расчет и хранение результатов групповых операций над данными (которые для этого разбиваются на блоки, для каждой из которых и вычисляются результаты), ведь чаще всего для статистики треуются именно MAX(), MIN(), SUM() и AVG(). Кроме того, граничные значения записей позволяют планировщику определить, какие из блоков данных содержат запрашиваемые значения, и распаковывать только нужные.
Из существующих реализаций были упомянуты InfoBright, InfiniDB и MonetDB, лучшей по быстродействию и функциональности оказалась InfoBright.

Александр Христофоров и Олег Анастасьев рассказали, как в социальной сети Одноклассники хранятся бинарные данные.
Организовать работу с более чем полутора миллиардами фотографий (каждая из которых еще и в четырех копиях разных размерах) общим объемом 200 Тб — задача не из простых. Главными целями при этом являются достижение максимально быстрого чтения и возможность расширения кластера. Поэкспериментировав с различными ФС (Reizer, HDFS, некоторые noSQL-решения) пришли к выводу, что нужно разрабатывать своё. Что и было сделано силами одного человека в течение 3 месяцев с использованием Java (выбор пал именно на Java, т.к. на ней же написаны многие другие компоненты системы).
Минимальная единица оборудования — один диск (а не один сервер). Каждый диск разбивается на сегменты по 256 Мб, принадлежность конкретных файлов сегментам хранится в хэш-таблице, располагающейся в памяти (плюс копия на диске). На каждый диск приходится только один активный сегмент (тот, в который идет запись).
Всего используется 24 физических сервера, фактор реплики - тройка. Маршрутизация (определение хранилища, на котором располагается конкретный файл) осуществляется на основе хэша id. Таблица маршрутизации построена с использованием подхода virtual buckets: пространство хранилищ делается во много раз раз большим, чем их есть на самом деле, и несколько виртуальных хранилищ могут указывать на одно реальное (это позволяет добавлять в кластер новые единицы без необохдимости перестраивать маршрутизацию, а также распределять нагрузку по хранилищам асимметрично, если это требуется).
Слайды презентации: http://www.highload.ru/2011/abstracts/13514.html.

Тезисы всех прозвучавших докладов доступны для скачивания в виде презентаций одним архивом.