Еще по быстродействию сайта – никудышняя структура БД

Еще по быстродействию сайта – никудышняя структура БД

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

Сегодня я хотел бы поговорить еще об одной напасти, которой страдают некоторые популярные движки, типа Битрикса, Шопскрипт и некоторые другие. Это проблема в совершенно дебильной организации добавления свойств в таблицах баз данных для различных свойств товаров.

Нормальная таблица со свойствами для N товаров должна выглядеть примерно так:
Товар 1| id |свойство 1 | свойство 2 |свойство 3| … |свойство m
Товар 2| id | свойство 1| свойство 2 |свойство 3 |… |свойство m

Товар N| id |свойство 1 |свойство 2 | свойство 3 |… | свойство m

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

Такая структура таблицы имеет количество записей по количеству товаров – N. И выделить из нее товары по любому набору свойств можно одним и очень быстрым sql запросом.

Теперь посмотрим, как хранятся данные в том же битрикс.

Там данные разбиты в несколько таблиц.

Одна таблица содержит название свойств. Например:
id_svoistva|name_svoistva
1|цвет
2|размер
..
M|материал

В другой таблице сами значения свойств хранятся в таком виде:
id|id_tovara|id_svoistva|znachenie_svoistva
1|1|1|зеленый
2|1|2|30x34x120

M|1|M|кожа
M+1|2|1|красный
M+2|2|2|30x22x110

2xM|2|M|кожзам

Суть в том, что в таблице со свойствами все данные содержатся последовательно. В результате в этой таблице строчек будет уже не совпадать с числом товаров, а будет умножено на количество свойств. Например, если у вас 10000 товаров и 12 свойств, то число записей в этой таблице будет 120 тысяч против 10 тысяч из первого, нормального варианта.

Но это на самом деле еще пол-беды. Настоящая беда начинается, когда надо выделить из этой таблицы товары по набору нескольких свойств. Если надо выделить только по одному свойству, то ОК, разница во времени будет определяться только числом строк и в общем виде не будет значительной.
НО!!!
Если вам надо выделить из базы товары по 2 и более свойствам, то такая структура может отдать данные только при использовании нескольких запросов. Т.е. одним запросом выделяется таблица с товарами по одному свойству, следующим запросом выделяются товары из первой таблицей по другому и т.д. по количеству свойств, которые надо выделить. Если написать sql запрос, который это делает, то он будет очень сложным и громоздким. Но самое главное, он сильно нагружает SQL сервер и требует очень много времени на выполнение.

Поэтому при выборе CMS обязательно поинтересуйтесь у разработчиков, какая структура БД для свойств будет использоваться на вашем сайте. Поддерживает ли система создание интернет магазина с нормальной структурой таблиц? Например, в MODx такая возможность есть. В других случаях, такие требования могут означать очень серьезные по времени и стоимости доработки.

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