Есть ли реальные преимущества использования РСУБД по сравнению с плоскими файлами в простой системе веб-документов (или базовой CMS)?

Если вы не можете назвать конкретную потребность в дизайне реляционных таблиц, значит, вы хорошо разбираетесь в плоских файлах. Стройте, как указано. В тот момент, когда вы можете назвать конкретную потребность, дайте им знать; обновление не так сложно, если ваше восприятие своевременно (то есть, если вы не в состоянии нормализовать данные, которые должны были быть интегрированы ранее).

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

Каков наилучший сценарий для вашего приложения CMS? Это успешно, и люди хотят использовать его больше? Если вы используете плоские файлы, будет сложнее обслуживать и улучшать вашу систему (например, сделать ее более надежной и добавить новые функции для будущих версий), а производительность будет плохо масштабироваться. Таким образом, «успех» в этом случае в лучшем случае недолговечен, поскольку успех означает все больше и больше работы при все меньшем и меньшем увеличении набора функций и производительности.

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

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

Что было бы здорово с простым сайтом, который загружался через JSON и jQuery, так это то, что сайту не нужно было бы загружаться при каждом клике. Просто соответствующие данные изменятся. Затем вы можете использовать хэши в адресной строке, чтобы отслеживать, где вы были (например, http://localhost/#about)

Каков прогнозируемый объем данных для CMS?

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

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

В то время как RDBMS может быть необходима для очень большой CMS, маленькая может очень хорошо работать с плоскими файлами. Я думаю, что многие CMS-продукты терпят неудачу в этом отношении, добавляя РСУБД, когда в них нет реальной необходимости.

Однако, если вы используете плоские файлы, есть проблемы с безопасностью, на которые обращают внимание другие пользователи. Еще одна проблема, с которой я столкнулся, заключается в том, что хостинг-провайдеры используют disable_functions в php.ini, чтобы отключить функции файлового ввода-вывода, такие как fopen() и подобные. Если вы размещаете свою CMS на компьютере, которым управляете, у вас не будет этой проблемы, но если вы используете стороннего поставщика, сначала проверьте.

Как оригинальный постер, я не вошел в систему, поэтому я до сих пор следую ответам в ответе (извините, если это плохой тон).

• Могут быть случаи, когда это находится на общем хосте.
• Хотя технически файлы JSON можно редактировать, это не так. Интерфейс администратора будет достаточно надежным, чтобы выполнять все операции по созданию/редактированию страниц.
• Размер каждой установки будет относительно небольшим -- 1-2 администратора, 10-100 страниц. Некоторые списки общих элементов могут занимать больше времени (например, фрагменты текста).
• Безопасность будет большой проблемой - какие-либо другие предложения по этому поводу?

Ну, разве нет проблемы в том, что они не доверяют любой системе баз данных? Разве проблема не больше в их мышлении, чем в технологии? Может быть, они боятся базы данных, потому что это кажется им сложным. В этом случае, если вы просто представите им какую-нибудь очень простую CMS (например, упрощенную CMS, которая, как я слышал, действительно проста, а процесс обучения очень быстрый), если они увидят, что все просто, то, возможно, они просто не поймут. неважно, что позади, будь то база данных или что-то в этом роде!

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