Генерация страниц из SQL-баз

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

И так далее. Эти данные, конечно, можно представить в виде обычной таблички:

<table>

<tr><th>Категория<th>Производитель<th>Артикль<th>Цена

<tr><td>Телевизоры<td>Samsung<td>8765<td>150$

<tr><td>Телевизоры<td>Samsung<td>2565<td>140$

<tr><td>Телевизоры<td>Sony<td>346<td>160$

<tr><td>Телевизоры<td>Sony<td>78<td>170$

<tr><td>Телевизоры<td>Sony<td>0456<td>130$

<tr><td>Телевизоры<td>Philips<td>78387<td>150$

<tr><td>Телевизоры<td>Philips<td>9368<td>145$

</table>

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

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

<tr><td>Телевизоры<td>Samsung<td>8765<td>150$

<tr><td>Телевизоры<td>Samsung<td>2565<td>140$

<tr><td>Телевизоры<td>Sony<td>346<td>160$

<tr><td>Телевизоры<td>Sony<td>78<td>170$

<tr><td>Телевизоры<td>Sony<td>0456<td>130$

<tr><td>Телевизоры<td>Philips<td>78387<td>150$

<tr><td>Телевизоры<td>Philips<td>9368<td>145$

Скрипт считывает весь файл в переменную, преобразовывает ее в массив, используя в качестве разделителя «<tr><td>», затем проходит по всем элементам массива, дробя данные на отдельные элементы, используя в качестве разделителя «<td>». И дальше анализирует полученные переменные (обычно деление на строки идет не по «<tr><td>», а по началу новой строки, а в качестве разделителя элементов строки используется не «<td>», а вертикальная черта «|»).

Этот вариант очень хорош для небольших баз данных. Но что, если у вас сайт рецептов приготовления пищи, на котором планируется разместить рецепты разных народов мира? Это же тысячи записей, при чем, не таких коротких строк, как прайс, а довольно больших, каждая из которых может содержать десятки тысяч символов описания того или иного рецепта. В простейшем случае, получается 1000 записей умноженная на 10 000 символов = база размером в 10 мегабайт. Довольно громоздко. Если каждому посетителю делать выборку из такой базы, нагрузка на сервер получается значительная. Такой объем данных лучше хранить в отдельных файлах. Может даже, как статические страницы. Но, это хорошо, если сайт имеет структуру вроде такой:

Русская кухня

1 блюда

щи

окрошка

…

2 блюда

картофельное пюре

овощное рагу

…

3 блюда

Квас

Пиво

…

Украинская кухня

1 блюда

борщ

суп с лапшой

…

2 блюда

…

и т. д.

Выбирая тип кухни, человек попадает на выбор блюд, выбирая тип блюд, человек попадает на перечень блюд этого типа этой кухни – нагрузка на сервер ничтожна… А если нужно, чтобы при выборе первых блюд человек получал перечень всех первых блюд, независимо от типа кухни? Или, выбирая плов, он мог получить все рецепты плова всех времен и народов единым перечнем?

Разделив данные на отдельные файлы и каталоги, реализовать данную задачу без критических нагрузок на сервер невозможно. Тут требуется единая база для быстрой обработки. Но текстовая база на 10 мегабайт в таком случае тоже не лучшее решение. Ведь, что для выборки всех первых блюд, независимо от типа кухни, что для выборки всех рецептов плова, что для получения одной единственной записи, необходимо считать и проанализировать всю базу. Снизить нагрузку можно только используя базы с ключевыми полями. Например, SQL. Именно в этом случае использование SQL-баз оказывается эффективней хранения данных в отдельных страницах или хранение их в текстовых базах. Тут затраты ресурсов на SQL-сервер оправдываются экономией ресурсов при обработке данных.