Накидайте актуальные CMS без БД

Очень просто. Вы наверное никогда не работали с фреймворками и понятия не имеете что такое сайты созданные с нуля по ТЗ.

Первый вариант подключал файл (include), в котором хранились данные страниц в виде массива (вес файла ~ 2 Мб) из которого брался нужный контент.

Второй вариант получал нужный контент через запрос к SQLite (вес базы ~ 2 Мб).

---------- Добавлено 17.01.2018 в 20:49 ----------

Вы поняли что написали ?

CMS на PHP это уже не статика.

Вы либо тему топика не читали, либо решили показать свою глупость. Ну или все вместе.

Спасибо за идею, вы только что придумали HTML 😆

Вы из какого года нам пишете ? Судя по продвигаемой философии где-то с времен популярности Web 1.0 🤣

Архитектура скажут почти все, и я повторю - архитектура. А зачем сразу 2МБ, которые могут перерасти в 100500МБ, может проще 3+ файла грузануть.

Реквайр файл вменяемого размера 10-100-ни мс. Памяти юзается мизер. Как показывает практика, число разделов на сайте исчисляемых 1000 редко встречается. Разделы дальше 3-4-5 уровня вложенности тоже не популярны (с) Кэп очевидность

• массив c уралми разделов содержащий данные про суб_раздел и ссылку на path к файлу с контентом.
• массив c уралми суб_разделов содержащий данные про cуб_суб_раздел и со ссылкой на path к файлу с контентом.
• .....массив c уралми суб_суб_разделов
• файл контента полученный из п.1 или 2.

как вариант, коих может быть немало. Зависит☝

Из файла можно по разному данные брать require, file_get_contents + (json_decode, SimpleXML иже с ним про xml, csv, parse_ini_file).

Но, да SQLite тоже уважаю :) И вот почему. К вопросу о скорости SQLite:

[sql] => SELECT `adomain`,  offsets(ads), snippet(ads, '[', ']', '... ') as result_snippet 

FROM `ads` WHERE `atitle` MATCH :ttl limit 20;

....

[:ttl] => atitle:камаз* atitle:новы*  atitle:зерновоз* 

....

[transaction_time] => 0.9531

....

Запрос к базе букварикс имеющей 43984091 записей - менее 1 секунды

Уже на этом месте стоит убицца апстену. Зачем этот файл, когда быстрее обращение к одному из n-файлов по паре килобайт.

Без базы даже форум можно сделать и они летают везде, на самых запущенных хостингах за 3 бакса

Давайте я навстречу свои предсказания выдвину.

Наверное, когда я писал и размещал сайты, вы еще под стол пешком ходили или на заводе работали.

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

(никакого http не было и в помине), примерно тогда-же, когда я имел email пользоваться которым

для отсылки писем родственникам приезжали люди со всей москвы, и да, модемы и соединение на 300 бод :) я тоже застал).

Нет, я стараюсь не работать с фреймворками покуда это возможно.

Просто потому, что часто это крайне неэффективно. Опыт знаете-ли.

Но порой приходится... бррр...

Зато у меня был свой собственный аналог смарти лет за 5 до того, как сам смарти мне попался.

А может и за 10, не помню уже.

Нет, по дебильным ТЗ я в вебе не работаю, смысла не вижу. Если ТЗ не нравится, за работу не берусь.

Да нет, я-то понял.

Это вы читать нихрена не умеете.

Еще раз: только конченные дебилы, каковых 99% будут при каждом визите на сайт не требующий динамического содержания запускать какие-то скрипты. Ферштейн :) ?

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

Для совсем тугих: скрипты запускаются для админки. Клиенты обеспечиваются уже готовыми html.

Часто такие решения вообще не требуют БД используя файловую систему (она тоже БД вообще-то).

Работают при обслуживании пользователей молниеносно, фактически со скоростью пинга.

Не требуют сложной конфигурации, наличия серверов итд итп, подходит любой копеечный хостинг.

Легко поддерживаются, стабильны в работе (резко ничего не ломается, тестирование требуется

только после внесения изменений) итд итп.

Из того года, в котором надо чтобы работало, а не "чтобы модно".

Из того, когда перед тем как делать башкой думали, а не мышкой в экран тупо кликали.

---------- Добавлено 18.01.2018 в 12:09 ----------

Так былиб индексы в памяти... дальше все почти со скоростью вынимания с диска.

Ну и... 1 секунда выж понимаете, что "на продакшене" это "приговор" ?

Есть, есть места, где без БД никуда.

Но современные разработчики лепят в базу всё подряд.

Что надо, что не надо, что точно не надо.

Причина этому к сожалению проста: квалификация не позволяет сделать что-то отличное от

установки какого-нибудь популярного говнокода написанного индусами. Часто не только их

квалификация, но и квалификация заказчиков.

И даже вопросов не возникает ни у кого "почему генерация страницы сопряжена с 300 запросами в БД"...

Классический пример: подсказки в поиск для магазина с 100 товаров.

В 99% случаев народ будет при нажатии кнопок аяксом их с сервера вынимать.

Представляете :) ? Вместо того, чтобы получить все названия всех товаров один раз асинхронно

и сохранить их в локалсторейдж и мгновенно реагировать на ввод со стороны клиента

будут туда-сюда аяксить до позеленения, со стороны сервера запускать скрипты, искать в базе :))) и возвращать ответы.

"Мама роди меня обратно".

ЗЫ. Тему смачную нашел, соседнюю

/ru/forum/983145

"Тормозит WordPress. 900+ запросов на странице!"

:)

Пока маленькие, пока возможностей минимум. Чуть больше требований и пипец. В 2018 искать без БД - это надо старовером быть :)

Лендинг или визитка из десятка страниц, каких в сети миллионы? Как два пальца обасфальт!

А зачем там кмс вообще ? Сверстал хтмл да закинул на сайт.

Чтобы хозяин сайта, который никак в этом не рёхает, не дёргал меня потом с просьбой "измените на сайте фамилию главного бухгалтера".

Разговор свернул в сторону БД vs файлы. По мне так, ничего плохого ни в файлах, ни в БД нет. Сам юзаю и тот, и другой вариант сугубо в зависимости от задачи. Полет нормальный;)

Конечно.

SELECT `adomain`,  offsets(ads), snippet(ads, '[', ']', '... ') as result_snippet 

FROM `ads` WHERE `atitle` MATCH :ttl limit 20;

....

[:ttl] => atitle:камаз* atitle:новы*  atitle:зерновоз* 

Такие запросы к базе с почти 44 млн. записей никто в здравом уме "на продакшене" задавать ни будет.

А если их, товаров, 100000. Или сегодня 100, завтра 1000000, а послезавтра 12🍿