28.4. Когда содержимое лучше сохранять в базах данных
Когда речь идет о содержимом, обычно имеется в виду статический текст, содержащий HTML. Не существует правила, которое бы констатировало, что содержимое никогда не может храниться в базах данных. Так, в случае с доской объявлений имеет смысл помещать сообщения в базу данных. Поскольку сообщения будут постоянно добавляться, их удобно рассматривать в качестве единиц, манипулируя ими по имени автора или дате создания. С другой стороны, сообщение об авторском праве, которое появляется в нижней части каждой страницы, больше подходит для текстового файла, который выбирается с помощью функции require.
Где-то между этим двумя пиками находится точка самоокупаемости. Причина заключается в том, что базы данных позволяют добиться компромисса. Они позволяют обрабатывать данные сложным образом и ассоциировать несколько частей информации вокруг общего идентификатора. Однако использование баз данных имеет и некоторые недостатки. Так, процедура выборки данных из базы данных занимает значительно больше времени, чем простое открытие файла и считывание его содержимого.
Многие Web-узлы представляют собой не что иное, как набор страниц, оформленных в одном графическом ключе. Работать с сотней файлов в каталоге легко: достаточно присвоить каждому из них информативное имя, которое бы соответствовало его содержимому, дать ссылку на него, например http://www.example.com/index. php?screen=about_us, и по-прежнему заниматься дизайном и навигацией. Ваш PHP-сценарий использует значение переменной screen в качестве имени локального файла, возможно, расположенного в каталоге screens. Разработчики могут продолжать работать над содержимым страницы в привычном ключе, так как они знают, что код должен храниться в файле about_us, который находится в каталоге screens. Но когда Web-узел имеет около тысячи страниц, хранение содержимого в отдельных файлах становится невозможным. Реляционная база данных позволит лучше организовать содержимое. Для Web-узла такого размера существует много вариантов навигации. В базе данных не трудно создать таблицу, которая бы связывала содержимое страниц с навигацией. Можно также автоматизировать гиперссылки, создавая односторонние ссылки между страницами. Это позволит автоматически задавать ссылку на страницу.
Наибольшей проблемой при реализации такого подхода является недостаток хорошего инструментария, необходимого для редактирования Web-узлов. Разработчики обычно пользуются методом загрузки файлов в редактор через FTP-протокол, и их очень трудно заставить пользоваться оболочкой базы данных. Стоимость обучения SQL разработчиков Web-узла может свести на нет выгоду, которую можно получить от размещения содержимого в базе данных. Таким образом, мы сталкиваемся с необходимостью создания своего собственного инструментария, предназначенного для редактирования содержимого. Логическим способом является создание собственного инструментария, опирающегося на Internet, так как кодирование приложения само по себе является большим проектом, особенно в ОС Windows и Macintosh. Как нетрудно догадаться, работающие в Internet редакторы нельзя назвать идеальными, однако для многих больших Web-узлов они могут быть удовлетворительными, поскольку альтернатива работы с таким большим статическим Web-узлом является, так сказать, большим злом.