kent666
Можно и так, можно и так. На файлах работа будет быстрее, если данные страницы не будут подвергаться изменениям, то есть будут полностью статичными. Да и дёргать и перегружать каждый раз БД без надобности не стоит. Обычно эти статичные страницы годами никто не меняет, зачем при каждом запросе лезть в БД для того, чтобы достать содержание страницы? Вот именно не за чем. Процессор на хостинге может тянуть в 100 раз больше нагрузки, чем MySQL, поэтому стоит беречь мускул от количества одновременных обращений.

neadekvat
Если 10 000 человек поломятся к мускулу -он падёт, если к файлу - выдержит. Цифры вымышлены, просто смысл показать =)
Кеш тоже у мускула не безграничный, если не ошибаюсь, то я где-то читал, что новые записи с кэша вытесняют старые, хотя не уверен в этом, может старая запись была на mysql.ru

imba, во-первых, вам не кажется, что эти цифры зависят от конкретного сервера, и обобщать было бы глуп.
Во-вторых, я имел в виду не кэш мускула, а кэш, которым вы будете управлять средствами php. Т.е. создаете класс кэширования, например, гененируете страницу - сохраняете в папочку. При следующих обращениях проверяете, существует ли такая страница в кэше и достаете ее оттуда, обходя путь генерации.

neadekvat
Именно для этого и была вставка: "цифры вымышлены", потому что резина у каждого сервера своя.

Спасибо. Значит будем работать в отдельных файлах)))

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

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

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

а) Статические ли это страницы?
б) Где они хранятся?

Структура проста:
Каталоги в корне документов:

/tests
/tests/pages

файл /tests/index.php

<?php // /tests/index.php

  require_once "config.inc.php"; // здесь подключение к БД

  $res = mysql_query($sql="SELECT name FROM pages")
     or die( "Error in $sql : <br>". mysql_error() );

  while($row = mysql_fetch_assoc($res))
  {
      $page = $row['name'];
      echo "<br> <a href=pages/$page.html >$page</a> ";
  }

файл /tests/page_creator.php

<?php // /tests/page_creator.php

    $page = @$_GET['page'];
    if(!preg_match('/^[-0-9a-zA-Z_]+$/', $page))
    {
       header("Location: 404.php");
       exit("No such page");
    }

  require_once "config.inc.php"; // здесь подключение к БД

  $res = mysql_query($sql=
  			"SELECT body FROM pages WHERE name = "
  				. ("'".mysql_real_escape_string($page)."'")
  		) or die( "Error in $sql : <br>". mysql_error() );

  if(!mysql_num_rows($res))
  {
     header("Location: 404.php");
     exit("No such page");
  }

  $name = "pages/$page.html";
  $h = fopen($name, 'w');
    while($row = mysql_fetch_assoc($res))
      fputs($h, $row['body']);
    $mt = filemtime($name);
    fputs($h, "\r\n<hr>Created at: " . date("r", $mt));
  fclose($h);
  $mt = filemtime($name);
  $gmt = gmdate("r", $mt);

  $l = fopen("creator_log.txt", 'a+');
   fputs($l, "nm=$name, gmt=$gmt\r\n");
  fclose($l);

  header("Last-Modified: $gmt");
  header("Content-Type: text/html; name=\"$page.html\"; charset=\"utf-8\"");
  readfile($name);

файл /tests/config.inc.php (можно заменить своим)

<?php // /tests/config.inc.php
   mysql_connect("localhost", "root", "") or die("Unable to connect to DBS: ".mysql_error());
   mysql_select_db("test") or die("Unable to select DB: ".mysql_error());
   mysql_query("SET NAMES 'utf8'") or die("Unable to SET NAMES" . mysql_error());

Дамп таблицы pages в выбранной базе:

-- Структура таблицы `pages`

CREATE TABLE IF NOT EXISTS `pages` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(50) NOT NULL,
  `body` longtext,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `name` (`name`)
) TYPE=MyISAM  AUTO_INCREMENT=4 ;

-- Дамп данных таблицы `pages`

INSERT INTO `pages` (`id`, `name`, `body`) VALUES
(1, 'page1', '<html>\r\n  <head> \r\n     <title>page 1</title>\r\n  </head>\r\n  <body>\r\n     content 1\r\n<hr/>\r\n<a href=page1.html>1</a>\r\n<a href=page2.html>2</a>\r\n<a href=page3.html>3</a>\r\n  <body>\r\n</html>'),
(2, 'page2', '<html>\r\n  <head> \r\n     <title>page 2</title>\r\n  </head>\r\n  <body>\r\n     content 2\r\n<hr/>\r\n<a href=page1.html>1</a>\r\n<a href=page2.html>2</a>\r\n<a href=page3.html>3</a>\r\n\r\n  <body>\r\n</html>'),
(3, 'page3', '<html>\r\n  <head> \r\n     <title>page3</title>\r\n  </head>\r\n  <body>\r\n     content 3\r\n<hr/>\r\n<a href=page1.html>1</a>\r\n<a href=page2.html>2</a>\r\n<a href=page3.html>3</a>\r\n\r\n  <body>\r\n</html>');

--

и наконец, последний, самый важный файл /tests/pages/.htaccess

#   /tests/pages/.htaccess
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteBase /tests/pages/
RewriteRule ^([-_a-zA-Z0-9]+)\.html$ /tests/page_creator.php?page=$1 [L]

Создаем оба каталога, разрешаем скрипту запись в них, создаем файлы, импортируем таблицу.
Вызываем localhosts/tests/index.php и ходим по ссылкам. Туда сюда несколько раз.
А затем заглядываем в файл /tests/creator_log.txt и отвечаем на вопросы.

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

А вот контент все-таки статический, по-моему.

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

Но идея для кэширования офигенная.. никаких там file_exists не надо. Правда, над структурой проекта придется подумать.

А зачем так? Для бэкапа наверное только удобно. Хотя можно и файлы сбэкапить, обойдя все каталоги. Ну может для инсталляции.

Страницы действительно статические, изменить что то в них нереально, если только не сносить файлы. Я что то смысла не увидел особого хранить статику в двух местах.

Наверное что-то упускаю?

а если снести?

Ну понятно что будет регенерация. От меня просто смысл этого всего ускользает...

Собственно, я пытался ответить на исходный вопрос тредстартера.

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

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

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

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


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

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

а догмы в программировании вредны чуть менее, чем инновационные идеи на пустом месте.