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

в PostregSQL можно файлики поставить и аудио/видео смотреть :)

эмулирует носитель инфомрция с репликацией

еще один facepalm.ЖПГ )))))))) пад стулом))))

нет это те кто здраво рассуждает, что нахера для сайта визитки фирмы, компании... или сайт портфолио страницы до 30. Ставить монстрозубую Джумло о_О ?

И эти люди с SQL тоже работают для проектов по крупнее.

О! Кажется я где-то это видел...

А, точно!

Я же писал уже об этом =)

У ваших оппонентов более убедительные аргументы.

* performance slowdown with a huge number of records

* no storage gain for binary fields (for example, numbers)

* non-validating SQL parser (an SQL query that works with Gladius may not be syntactically correct)

* all strings are considered binary and should always be Unicode safe

* no specific collation or character set support

* cannot SELECT calculated or immediate values

* no specific date/time functions (as of Gladius DB v0.6.2)

Последний релиз 2 года назад, на форуме поддержки аж 3 сообщения. В списке багов ни одного исправленного за эти же 2 года.

И это при том, что PHP движок за 2 года достаточно сильно изменился и в какой то степени на его новой версии, старый код может работать не корректно или вообще не работать.

Ок, скачиваем, запускаем пример, смотрим. Таблица - это файл где данные хранятся в виде сериализованного массива. После первой же тысячи записей, хостинг выпрет вас за превышение нагрузки на cpu .

Orangesoda

Это мое ИМХО.

Каким же надо *** что бы для сайта на 5 - 30 страничек мучать сервак джумлой.

Ржу не магу)) с кто на этом настаивает)))

Да никто на этом не настаивает!

Если на сайте есть более менее серьезные манипуляции с данными, то все эти CMS файловые не пригодны для использования.

Это уже мое ИМХО.

Вообщем выложу некоторые CMS без мускула на которых катаются проекты с постоянно обновляемым контентом

http://www.exbb.org/

http://forum.myupb.com/

http://flatpress.org/

http://linkorcms.ru/ - mysql и flat file

>Страница сгенерирована за 1.05 сек. и 15 запросов к базе данных ( PHP: 12% БД: 88% )

>Желательно: MySQL любой версии, GD, MbString, Iconv.

Таки да, работает и без базы, но лучше всего с базой :)

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

Три другие ссылки это примеры проектов с постоянно обновляемым контентом: форумы и блог.

То есть это даже не сайты визитки для которых извращенцы лепят джумлу.

По поводу форумов и блогов на "плоских файлах" я могу сказать респект ребятам, так как там есть

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

Хотя в таких проектах как Gladius BD поддерживается синтаксис SQL. И все же не нужен мускул.

Как я на это смотрю ?

CMS на файлах идеально подходят для

сайт визитка, сайт портфолио, домашняя страничка, сайт-блог

Для форумов, так как там все же больше работы с данными и довольно часто обновляемой я все таки брал бы CMS на MYSQL, PostgreSQL.

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

В чем проще? Не нужно сообщать инсталятору данные доступа к базе? Ну так надо ведь еще права прописывать или отдавать инсталятору права на фтп. Так что в среднем одинаково.

Согласен.

Согласен.

Ы? это здесь каким боком? тот же мускул к примеру так же кроссплатформенен.

В принципе согласен. Не особо часто оно и надо, и не всегда файловая база == текстовые файлы, но в принципе засчитано.

кеш спасет отца русской демократии. Хотя иногда это может быть плюсом.

Ну тут уж не надо путать мух и котлеты. Такие вещи надо лечить на уровне проектирования ядра фреймворка.

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

Может будем писать на асм? Требования еще меньше будут :)

В принципе засчитано, но чисто как "фрихосты без мускула под доро-саты"

Зато в реляционной базе это гарантия целостности? :)

Конечно встроенные в базы средства контроля и лечения мощнее чем файловые, но не стоит их идеализировать.

хм.. мне как-то в голову не приходило каждый раз кодить запросы вручную.

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

Нужно отделять мухи от котлет и форму от содержания.

И на много дешевле выходит одно бесплатное решение чем другое? :)

они растягиваются... ой, чего это я?

В общем, а вам не пофиг чего там делает класс базы данных? Не вручную же пересматривать каталоги :) Да и не обязательно тут будут каталоги. Для небольшой таблицы можно тупо в одном каталоге хранить все записи, ключи в имени файла хранить. Запрос содержимого каталога (с масками если нужно) и потом уже по результату выбрать нужные файлы.

И не надо придумывать граничные условия при которых такая схема не пройдет - файлы вообще не для любых задач.

memcache прожорлив в плане памяти. Как правило кеширование готовых страниц на фронтэнде как раз таки в файлах делают. Представьте миллион страниц в оперухе. Но конечно от задачи зависит.... Частенько и в базе кеш хранить вполне оправдано (один простой запрос вместо сотни мелких/сложных).