Является ли создание уникального HTML-файла для каждой статьи хорошей практикой?

Question

извините за плохое название темы, я не мог придумать ничего лучшего;)

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

спасибо всем и извините за плохое английское письмо: P

Answer 1

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

И если вам нужно изменить макет или отредактировать статью, вы можете просто восстановить страницу.

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

Плюсы:

• Более быстрый поиск страниц
• Меньшая нагрузка на ваш веб-сервер
• Меньшая нагрузка на сервер базы данных

Минусы:

• Нужно проделать дополнительную работу для обновления кэша при изменении статьи
• Не может быть никакого динамического контента на странице
• Вероятно, проблемы вообще нет.Большинство веб-серверов способны обслуживать большое количество динамических страниц (преждевременная оптимизация - корень всех зол).
• Существуют и другие способы ускорения работы, которые не имеют вышеуказанных минусов.Вы можете кэшировать результаты запросов в Memcache и / или использовать APC-кэш для ускорения вашего PHP-кода и уменьшения количества дисковых операций ввода-вывода.

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

Answer 2

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

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

Answer 3

Без полуприличной системы шаблонов вам придется хранить полную статью И макет и стили страницы в одном файле.

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

Answer 4

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

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

Проще добавить / удалить / отредактировать статью прямо из админ-панели, со статическими страницами вам придется искать путь через html-код.

Этот список можно продолжать и продолжать ...

Answer 5

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

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

Обычный и предпочтительный способ сделать это:

• хранить и загружать контент из БД
• иметь шаблон (верхний и нижний колонтитулы) для страницы и вставлять только содержимое
• имеет панель администратора с редактором (настолько богатым, насколько это возможно), где вы можете изменять содержимое articel

Answer 6

Я начал спрашивать себя, почему заинтересованная сторона может попросить вас внедрить систему таким образом. Почему он / она заботится, если ваша система отвечает требованиям? Есть два возможных ответа на этот вопрос:

• Заинтересованная сторона - что-то вроде контрольного урода; например бывший технарь, который любит вмешиваться в то, что делают его разработчики.
• У заинтересованного лица был плохой опыт в прошлом; например с предыдущей системой, в которой контент был «заблокирован» в базе данных с громоздким внешним интерфейсом, который сделал жизнь адом для пользователей.

С этой точки зрения, как бы вы решили проблему? Я считаю, что вам нужно понять, почему заинтересованная сторона просит об этом. У него есть какая-то искренняя забота? Можете ли вы решить эту проблему при проектировании системы?

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

Я думаю, вам нужно:

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