Почти статичный сайт - нужна ли CRM?

Да и в файле их можно структурировать, без проблем, хоть в каком, хоть в ини, хоть в json.

Но выросло уже целое поколение людей, которые "всё говно тянут в БД", и их не переубедить.

Они щаз тебе начнут рассказывать, что сортировку и поиск в 500 товарах можно сделать только на стороне сервера, и "другого в этой жизни не дано".

ЗЫ. Некоторые из этих людей уже проникли в команды, которые пишут популярные движки.

Так и получается, что перформанс логи у них в БД пишутся... к примеру. А чё, этож современно !

По-моему, я на примере достаточно понятно показал, о каком структурировании шла речь. Дело не только в разметке.

Отдельно ЦМС и БД не рассматриваете? Например, возможность убирать/не устанавливать ЦМС (оставляя только переднеплановый движок), когда она не нужна. Одним махом решается куча проблем с безопасностью. Сейчас практически весь хостинг, включая копеечный, рассчитан на динамические сайты и использование БД. Не задумывались, почему? ;)

Во-во, хотя SQL (или более примитивные аналоги) используется в том числе и при сборке статичных сайтов. А то что после сборки он перестает использоваться (как и исполняемый код сайта в целом), так это один из осн. недостатков таких сайтов. Простейший поиск по сайту отсутствует и т.д. В общем сайты, получаемые в результате работы генераторов стат. сайтов, получаются слишком немощными. «Запилить описалово» на джитхаб, если жалко копеечку на обычный хостинг, еще можно, но не более.

P.S. Что касается конкретно MD, о кот. ты ранее писал, лично мне он не нравится. Предпочитаю использовать для контента чистый HTML, возможно, с шо(р)ткодами, но не для таких простых вещей, как в MD. Т.е. я против гремучей смеси какого-то доп. языка разметки с HTML в контенте практически любого материала.

_SP_, при использовании БД первостепенное значение имеет не само хранилище, а язык запросов. Про хранилища выше уже писали. Можете хранить «хоть в ини, хоть в json», хотя как индексировать потом эти данные, ХЗ. Отдельно прописывать индексные структуры? Индексировать при каждой загрузке?

При использовании БД первостепенное значение имеет то, какие тормоза ты в результате получишь, какие гемморои по поддержке, как часто она падает на шареде каком-нибудь итд итп.

А с запросами да... руки бы оторвал большинству тех, кто их пишет. И в плечи потом вставил.

В целом, поддержка решения без БД или без сложных запросов в 100500 раз проще.

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

Если бы он собирал эти данные со стороны клиента (а сервер крутился локально там-же), то я уверен на 99.9%, что за 2-3 дня удалось бы справиться.

Загрузке ? Индексировать ?

Вы что хотите делать расскажите, а я расскажу вам как это можно делать :).

Заметьте, у нас задача "почти статичный сайт". Но это в целом не важно.

Для варианта поиска по 500 товарам вы вообще можете всё отдать на сторону клиента 1 раз, и после этого со стороны клиента что угодно и как угодно искать перебором (о боже да, перебором искать, прикиньте :). И будет летать по сравнению с любым сервер-сайд решением. Люди попросту не верят, что то что им показывают - "это уже в интернетах", они задают вопросы "этож демка ведь да, вы ведь не с сервером нашим щаз работаете, а со своим компьютером ?".

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

Ага, видал такое. Особенно интересно наблюдать, когда товаров сначала становится 600, потом 6000 и т.д. :D

---------- Добавлено 21.11.2019 в 14:37 ----------

P.S. У нас «задача» от «почти статичный сайт» до «нужна ли CRM CMS?». Причем в сайте уже используется БД.

---------- Добавлено 21.11.2019 в 14:39 ----------

P.P.S. Давайте хоть в этой теме обойдемся без «священных войн». Пусть каждый предлагает свой вариант, а ТС выбирает.

Если запись о товаре - это 100 байт, то при 6000 товаров имеем 60 000байт. 60кб.

Мне не кажется это слишком большим объемом данных, а вам ?

Если со стороны клиента возникают какие-то проблемы с "поиском перебором" нет никаких проблем локально собрать любые индексы.

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

К пред. посту. Хотя я почти уверен, что ТС либо забьет на это дело, либо выберет вариант для домохозяек. Иначе бы мы (в широком смысле) уже бы давно межзвездные перелеты совершали.

Кстати предложенный мной вариант предусматривает его расширение до инструмента для домохозяек.

а я именно об этом и писал, а не о разметке ;)

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

P.S.

с точностью наоборот ;)

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

P.P.S. я много раз писал, клиентам нечего делать во внутренностях сайта - этим должны заниматься специалисты!

и при этом плодят столько проблем, которые ещё ни одна цмс не решила ;)

Зачем всё в кучу мешать? Речь совсем о другом.

1. При правке статьи в админке затрагивается 1 статья, а никак не весь сайт.

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

3. Во внутренности сайта клиенту действительно лезть незачем, и про это здесь речь вообще не идёт.