Делать двиг на бд или файлах?

По любому БД. Знакомый программист был прав. От 10 000 страниц с таким количеством инфы на файлах и конфликт и тормозить будет.

Это он про чтение файла? Какие преумищества Вам даст база? Она будет использоваться в режиме SELECT content WHERE id = n;

Да, про чтение файла.

Так даст мне база преимущество?

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

1. самописная система управления = всегда проблемы. ИМХО. И заказчику это объясните. сделать можно, поддерживать можно, но невыгодно. особенно в перспективе лет пяти скажем.

2. Самый устойчивый вариант работы, вообще ненапряжный для сервера - это когда сайт представляет из себя набор html страниц. Естественно, не призываю делать сайт ручками - некоторые движки работают с базой, а на выходе генерят html страницы. Подходит для сайтов с медленной скоростью обновления информации.

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

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

А вообще в чём необходимость вопроса? :) БД сейчас на любом хостинге есть. Если вопрос в скорости, то файлы лучше только в случаях статичности данных.

Кривые руки = всегда проблемы.

Вопрос в скорости. А страницы будут исключительно динамические.

Видимо только бд.

Чего, чего. А ну бегом читать про flock

А зачем блокировать файлы при чтении? :) Или я не понял ход мыслей... При записи пральна, нужно будет блокировать файлы, в момент чего чтение будет недоступно, в итоге будем иметь висяк пока файл не станет доступным. Ну или просто можно будет выдать мессагу аля "пардон, зайдите чуть позже".

С БД таких проблем не будет.