CMS с MySQL или без - помогите определиться

да хоть 10000 программистов. Почему на серче, который сидит на сервере, при 300к просмотров и базе мускуль, и у меня на форуме где 15к просмотров, и который сидит на шареде МХ, вместе с 9 сайтами, оба работают одинаково по скорости.

Функционал обрезан у меня -да.

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

Мускуль - это один файл, и как его не оптимизируй- грохнуть его куда проще, чем 1000 отдельных.

дело выбора. В 90% использование мускль неоправдано

с каких это пор ? или это только на вашем "шареде" по особому заказу ;) ?.. MySQL вообще то - сервер доступа, каждая таблица может хранится как в одном так и в нескольких файлах. вообщем, учим матчасть -> потом советуем...

В 90% про мускуль пишут полный бред, то называя его файлом, то сравнивая с 10к тысячами файлов.

Мне очень хочется посмотреть, как вы будете реализовавать выборки по таким файлам с определенными условиями. Если у вас задача "прочитать файл", то да, хранить инфу в файле быстрее. Но простейшая операция выборки по параметрам, займет у вас в тысячу раз больше ресурсов, чем такая же выборка в базе данных.

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

Нужен примитив - используем файлы. Нужны возможности - используем базу.

Мы про кластеры на диске, или про файлы?

Формально база мускуль является файлом, в моем понимании. Как вариант ее можно разбить.

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

В общем случае, он дает кучу запросов к одному файлу, который и есть база

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

Это быстрее.

даже формально запросы к серверу MySQL нельзя рассматривать как поток запросов к одному файлу. и не путайте - эта СУБД построена на основе именно файловой системы, еще в 3-шке (не так давно) максимальный объём таблицы был ограничен 4-мя Гб - из за ограничения файловой системы на размер файла.

так речь то и о том, что мускуль - это серьезно. А делать сайт визитку на джумле или ВП- бред.

Spine бы на вас натравить, да он отсюда ушел...

Я практик. Мне опять таки это не нужно. Я вижу результат. Он не в пользу мускуль при посещаемости до 2-5 к и адекватном php

СУБД - это не просто текстовый файл, который где-то там лежит ;)

Если говорить о файлах, то СУБД имеют хорошо развитые средства поиска по большим массивам данных. Это как минимум B-Tree-подобные индексы. Вы о них и не слышали. О query cache и других кешах тоже нет.

Также в СУБД хорошо реализован механизм конкурентного доступа к данным, блокировки всякие, транзакции. Я уже молчу о различных выборках по нескольким таблицам, с различными параметрами. Это не считая процедур и прочих радостей жизни.

Сравнили теплое с мягким... Мда.

Это вы о том как MySQL базы данных хранит? Это не один файл. Учите матчасть. Грохнуть их так же просто как и 1000 файлов. Одна команда.

Почему?

У вас какое-то неверное понимание, на основании которого делаете далеко идущие выводы.

К какому одному файлу? Какая куча? Каких запросов? Вы как-то понятней излагайте свои мысли.

У меня есть несколько сайтов. Один из них на Joomla 1.5. Работает это чудо на дешевенькой VPS-ке с 200 Мб памяти. Посещаемость больше 10К. Сайт летает. Ужас, правда?

Ладно. Вот вы говорите, что вы мол практик. Ок.

Банальная задача. Есть каталог товаров. Нужно выбрать товары по параметрам. На MySQL это делается в рамках одного или двух запросов (если количество параметров и их значения неопределенные). Как вы реализуете такую простую фичу на файлах?

чтобы без MySQL? Берём из файла настройки Sphinx... :D

Много иронии,много всего.ТС в начале написал, что ему надо.Под этот проект подходит и с БД и без БД.Дело вкуса.Кому Land Rover, кому Ferrari.

По другому: кому ленд ровер, кому велосипед.