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

Question

Проект

Меня попросили поработать над интересным проектом - что составляет базовую веб-CMS - который использует HTML / CSS / jQuery с PHP. Однако одно требование состоит в том, что не будет базы данных для размещения данных (им нужны плоские файлы для документов / страниц - предпочтительно в формате JSON).

В самом базовом смысле, он будет использоваться для генерации HTML-страниц через очень "нетехнический" интерфейс. Каждая установка будет содержать только около 20 страниц, но некоторые из них могут получить до 100. Должно быть достаточно легко перейти на сервер с поддержкой PHP и запустить его, при этом потребуется очень мало настроек.

Что там

Существует множество опций CMS и довольно много версий плоских файлов. Но OSS или другая существующая CMS не вариант. Им нужна простая система приличия.

Исходные мысли

Так что плоские файлы это ... но я действительно хотел бы получить некоторые отзывы о недостатках, и если стоит усилий, чтобы попытаться убедить их использовать что-то вроде MySQL (SQLite или CouchDB отсутствуют, так как нет из серверов может быть настроен для их запуска в настоящее время).

Конечно, файлы документов довольно просты, но мы также говорим об информации для входа в систему для 1 или 2 администраторов на установку, нескольких списков, а также настроек / настроек (которые также могут быть легко сохранены в файле с защита).

Дилемма

Если есть преимущества использования MySQL, а не файлов, отформатированных в JOSN, и некоторых массивов в простом проекте, подобном этому, - помимо моих предвзятых представлений :) - я обязательно их спорю.

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

Буду признателен вам за понимание и мнения.

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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