Задать вопрос

Какие достоинства хранения шаблонов в БД?

Некоторые CMS хранят шаблоны в БД. Извиняюсь за глупый вопрос, но в чём профит этого шага? Много раз сам сталкивался и в WprdPress проектах и в других системах, когда ищешь какую-то строку или надпись из шаблона поиском по всему проекту в PHPStorm - её нигде нет, потом оказывается в БД лежит.
На мой взгляд это сильно затрудняет работу для новых разработчиков, повышает требования к документации. Но может быть я не прав и просто не вижу преимуществ...
  • Вопрос задан
  • 373 просмотра
Подписаться 1 Простой Комментировать
Решения вопроса 1
никаких, так делают имбицилы
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
Sanes
@Sanes
Кеш БД легче хранить в RAM, чем дисковый.
Это относится к шаблонам, а не к какому-то значению из него. Такой подход в Modx по-умолчанию.
Ответ написан
Комментировать
angrySCV
@angrySCV
machine learning, programming, startuping
производительность БД выше чем у файловой системы
Ответ написан
@stratosmi
Удобство модификации программным путем.
Ответ написан
Профита от этого никакого нет. К тому же, так делать плохо. Более лучший вариант - хранить шаблон в виде файла, а в БД - ссылку на него.
Ответ написан
Комментировать
PretorDH
@PretorDH
HTML5, CSS3, PHP, JS - люблю в чистом виде.
При проектировании CMS все остаётся вопрос в СТРУКТУРЕ разделении КОНТЕНТА редактируемого контент менеджером и статичным ШАБЛОНОМ в который этот контент помещается. И баланс здесь очень скользкий. Я бы сказал это искусство приблизится в плотную к этому балансу. Да и сам бланс зависит от бизнес модели, структуры компании, методов работы и ещё многих факторов.

(Шаблоны) Одна крайность - прописать все блоками, и тогда контент менеджеру останется только тупая работа по вбиванию текста картинок в блоки. Но тогда на каждый "пук" практически для каждой статьи нужно будет дергать разработчика, что тот подправил вид. Это хорошо для проектов с почасовой оплатой услуг DEV-компании. Разработчику много постоянной работы и максимальное оплачиваемое время.

(Контент) Вторая крайность - сделать простую серверную сборку с контента хранящегося в базе данных. И пусть контент менеджер корячится с версткой страниц сам. Разработчики только минимально подправляют стили по требованию. База максимально простая, контент стандартизирован в одной таблице. Только динамические данные подтягиваются отдельно. Это идеальный вариант когда разработчику платят фиксированную суму, а потом платят долгий срок за поддержу продукта. Максимум свободного времени у девелопера. Но заказчик не понимает за что платить, работает же он, а не программисты.

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

P.S. Фактически на такой маленькой фиче как баланс структуры, шаблонов и контента, построен весь рынок веб разработки. :)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы