Читая всякие форумы по CMS-строительству, наблюдаю странную на мой взгляд, картину - люди стараются нагрузить вэб-сервера дурной бесполезной работой, не имея на это никаких существенных оснований. Речь веду о запихивании в БД всего, что под руку попадется. Например, многие современные CMS грешат тем, что хранят в БД те данные, которым там совсем не место - шаблоны страниц, стили и т.д.

Мне кажется, что такой подход - результат того, что вэб-приложения разрабатывают люди, привыкшие создавать софт для настольных систем, для которых хорош принцип "компьютер железный, вот пусть и работает!". Но в вэб такой подход совершенно не приемлем. Имхо. 

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

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

Вот четыре основные вещи, дающие абсолютно лишнюю нагрузку:

1. хранение стилей в БД
2. склеивание стилей в один большой блок
3. хранение шаблонов в БД
4. использование "кросс-БДшного" кода.

Рассмотрим их более подробно.

Проблема хранения стилей в БД.

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

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

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

Во-вторых, возможность редактирования файлов через админку вовсе не обязует хранить данные в БД — дайте пользователю возможность редактирования через админку стилевых файлов на сервере и обращения к БД (как и бесполезные вызовы скриптов) больше не нужны. Если результат одинаковый, то зачем платить больше?

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

Второй аргумент — якобы упрощение переноса сайта с одного хоста на другой. Типа просто экспортировали БД на старом хосте и импортировали на новом и все само собой правильно настроилось. Но ведь при переносе сайта вам все равно придется переносить и скрипты (сам код CMS), так какая разница переносить только файлы CMS или файлы CMS плюс файлы дизайна??? Один фиг копировать придется. 

Склеивание стилей в один большой блок.

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

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

Хранение шаблонов в БД.

Это наверное наибольший из маразмов, т.к. ни один вменяемый дизайнер/верстальщик ни за какое бабло не станет проводить редактирование шаблонов в броузере. А других аргументов в пользу хранения шаблонов в БД просто нет. Про перенос с хоста на хост я уже сказал, тут тоже никакого выигрыша нет.

Проблема ужесточается тем, что времена когда страница сайта строилась из одного шаблона, давно прошли и ныне страницы современных сайтов собираются из кучи мелких шаблончиков - под каждый блок сайта свой шаблон и, возможно, не один. В результате имеем по одному лишнему обращению к БД на каждый из микро-шаблончиков, а то и более. Зачем? Только чтобы потешить свое ЧСВ, типа идем в ногу со временем и активно используем передовую идею запихивания хлама в БД? Смешно. 

Кросс-БДшные CMS.

Конечно офигенно круто, если ваша CMS может, практически без каких-либо изменений в коде, работать с почти любой, установленной на сервере, СУБД. MySQL? Пожалуйста. Postgre? Легко! MSSQL? Да не вопрос!!! Глобальная победа универсальности в рамках отдельно взятого сайта!

На практике же 80% всех сайтов сидят под MySQL и большего им не нужно. А там где нужны транзакции и прочие мега-фишки, требующие более взрослых СУБД, используются и более другие CMS, заточенные под соответствующие задачи. Зато БД-шная универсальность обходится совсем не так дешево, как кажется. И для программистов и для серверов.

Холиварить тут можно очень долго, поскольку найдется не одна сотня разработчиков, которые будут утверждать, что строить запросы, используя какую-нить ActiveRecord в стопиццот раз проще, чем вручную писать SQL-запросы. Но они лукавят, т.к. если запрос использует пяток таблиц, завязанных перекрестными ссылками в тугой узел, обильно приправленный полу-десятком условий с сортировками, группировками и прочими JOIN'ами, то объем кода, который требуется написать, чтобы все это добро впихнуть в ту же ActiveRecord становится в несколько раз больше, чем сам чистый SQL-запрос. И самое противное, что разобраться в этой мешанине уже совсем не так просто, как в чистом SQL.

В качестве примера, для разминки мозга, можете сами попробовать запрограммировать в ZendFramework или CakePhp вот это (совершенно реальный запрос из моего блога):

SELECT
s.id, inner_uri, category_id, created, last_modified,
title, menu_alt, link_target, author, editor,
COUNT(c.id) as comments,
ua.user_name AS author_name, ua.user_email as author_email,
ua.user_avatar as author_avatar,
ue.user_name AS editor_name, ue.user_email as editor_email,
cat.cat_title AS category , p.content,
p.commenting, p.comment_thru
FROM
t1_module_blog_posts p
LEFT JOIN t1_sitemap s 		ON s.id=p.map_id
LEFT JOIN t1_module_blog_comments c ON c.map_id = s.id
LEFT JOIN t1_users ua 		ON ua.user_id = s.author
LEFT JOIN t1_users ue 		ON ue.user_id = s.editor
LEFT JOIN t1_categories cat	ON s.category_id = cat.cat_id
WHERE
visible=1
AND (s.category_id=0 OR cat.cat_visible=1)
AND (valid_thru=0 OR valid_thru>=1279452356)
AND s.created<1279452356
AND (s.permission='' OR s.permission IN
('admin_panel_access', 'authorized-user', 'developers-only', 'manage_categories',
'manage_content', 'manage_groups', 'manage_menus', 'manage_modules',
'manage_perms', 'manage_prefs', 'manage_settings', 'manage_users', 'module_settings'))
AND (s.category_id IN ('25', '21', '18', '19') 
OR s.category_id=0)
GROUP BY p.map_id
ORDER BY created DESC
LIMIT 20, 140

Сделали? Сравнили читаемость? А заработало? И с первого раза??? 

А теперь прикиньте, что каждый запрос (от простейшего до монстрообразного) требует таких же "напрягов" от вас, как разработчика, а потом еще движок, при каждом обращении к БД будет всю эту вашу писанину парсить, сверять с реальной структурой БД и строить тот самый чистый запрос, от которого вы так долго пытались избавиться который вы так долго пытались "зашифровать" для фреймворка. Работа ради работы?

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

Итог

Задумайтесь. (С) National Geographic.