Ищу Candidat CMS

DenisVS, идёт обсуждение концептуальных положений сайтостроительства.

В случае блогов, я соглашусь с вами.

Цены же тоже меняются в магазине, иногда почаще чем stock. Но в данном случае это не важно.

Да, сложности, созданные на ровном месте. И не просто сложности, а дичайший overengineering.

Важно. Я не приветствую подход "и так сойдет".

Да, их не скрывают, но перемещают в конец листинга. Если же товар больше не производится, его скрывают.

Слышал, я же про них и говорю. Это и есть шаблон, куда подставляется значение переменной. Но это в целом не важно, его можно и из файла прочитать, другой вопрос зачем? Ну лежит он себе в базе. Доступ к нему быстрый, эти значения легко кешируются через cache-middleware прослойку. За сутки это значение прочитается из базы ну пару раз. Критично? Нет.

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

Но в целом, проблема не в этом. Проблема в том, что

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

И вы так и не ответили на вопросы даже малейшим псевдоалгоритмом:

- как найти все страницы где фигурирует товар (реверсивный поиск)

- как найти сиблингсы товара в выборках, в которых он фигурирует

Только чур не использовать SAP HANA, Gremlin/TinkerPop, ArangoDB и прочие графовые базы.

Да какая разница, с чего начинали?! Вышли-то на интересные моменты, о которых стоит хотя бы поговорить

Да и название ровно этой же логике подчиняется. Шаблонов то много может быть где название может быть. Кроме того, счет, кп и др. документы которые надо отдать в pdf/xls/doc и тд.

Правда для любого из конфигов, где данным такого типа самое место, не обязательна БД. Скорее даже вредна - конфиг всегда в файле🍿

Про товары, если их тысячи, соглашусь с мнением - проще в БД.

Костылить, всеми правдами и неправдами открещиваясь от использования БД - интересные моменты?

Нет, а вот теоретический обоснуй под это - да

Я интересного обоснуя не видел. Я работал в проекте, где несколько десятков операторов постоянно скармиливают системе документы, плюс сама система постоянно скрапит сайты, потом найденные доки тессарактом разбираются и полученные данные пихаются в Монгу - уж точно в работе с БД не было проблем, хоть это и не РДБ, но все таки база) А читать обоснования для системы под несколько сотен страниц - неинтересно. Все равно там проще юзать БД, избавить себя от головняка с поиском и проч