Что такое по Вашему CMS без базы / файловая CMS?

Для своих целей сделал как-то CMS, которая всё берёт из Subversion (тоже, в каком-то смысле, БД), и автоматически перегенерирует все изменившиеся страницы сайта скриптом, вызываемым как хук post-commit.

Плюс - все страницы статические (тем не менее, на таком CMS вполне можно делать хоть наши любимые блоги, хоть что-то ещё), такой сайт минимально загрузит Web-сервер при прочих равных.

Минус - для "обычного" пользователя всё равно нужна минимальная Web-морда, поскольку средний пользователь Subversion не пользуется.

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

Мускул тоже хранит данные в файлах. К.О.

Есть готовые решения, такие как:

Gladius DB

textSQL DB - вроде так называется она

Я в Template CMS юзал обычные текстовые файлы данные разделял специальными символами. собственно свой велосипед.

В Template CMS 2 использую XML для хранения данных - это очень удобно.

Не надо хранить вот так, как в Template CMS 1:

admin{|}11f504164d5a111d6a820e11614a1109{|}awilum@msn.com{|}admin

а вот так:

<?xml version="1.0" encoding="UTF-8"?>

<item>

	<user_name><![CDATA[admin]]></user_name>

	<user_password><![CDATA[11f504164d5a111d6a820e11614a1109]]></user_password>

	<user_email><![CDATA[awilum@msn.com]]></user_email>

	<user_role><![CDATA[admin]]></user_role>

</item>

плюс свой велосипед для работы с этими данными :)

Простота установки?

да

Фрихосты без базы?

да

Простота переноса?

да

SQL - это гибкая работа с контентом.

Файлы - топорный вариант адаптации к хреновому хостингу.

Имея контент в базе, никто не мешает сделать его моментальную генерацию в статику, если есть такая необходимость.

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

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

Так что удел файловых цмс - это дорвеи, сплоги и прочий мусор.

Скорость.

Ничего так, что SQL это всего лишь (утрирую) язык обращения к информации хранящейся в файле?

не факт и не всегда.

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

Речь идёт о скорости доступа - выборака информации это уже дело второстепенное. Можно организовать такую FS, что индексы будут "нервно курить в сторонке".

Я этого не отрицаю, но, повторюсь: при грамотной организации файловой структуры, ПХП-шные аналоги СИ-шных функций просто не потребуются.

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

я когда-то читал про "плоские файлы". но руки в своё время не дошли. писал в свое время и под один файл для базы, и под деревья папок. тут всё зависит от задачи.

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

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

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

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

Хотя и любое свое решение имеет право на жизнь. Например, сейчас мне пишут систему, которая будет работать на связке MySQL+MongoDB - основные данные будет хранится в MySQL и работа с ними будет проводить через ORM, и похожий но со своими особенностями слой будет лежать над MongoDB, но в этой NoSQL базе будут хранится дополнительные поля для материалов и разделов.

Первоначально хотели делать используя паттерн EAV, но моя настороженность и мнение программиста всё же объединились вместе и мы пришли к выводу, что это будет не совсем рациональный подход. С другой стороны минусом NoSQL (в частности MongoDB) есть средняя отказоустойчивость и время для восстановления после сбоев. В итоге, сошлись, что основные данные храним в MySQL и если MongoDB в дауне или же идёт процесс восстановления данных, то соответствующие данные просто не учитываются при поиске и не отображаются.

Сейчас должна выйти новая версия MongoDB и там будет журналирование, но пока что полного доверия нет, поэтому остановились на этой схеме.

И ? Надеюсь не надо объяснять, что под sql подразумевается работа с базой, или же еще базы данных перечислить ?

Вообще скорость доступа и измеряет выбор информации.

Базы данных - это не обязательно SQL-базы данных. Поэтому замечание Brand from Amber справедливо.