Является ли сериализация PHP хорошим выбором для хранения данных небольшого веб-сайта, измененного одним человеком?

Question

Я планирую архитектуру сайта PHP. Это будет небольшой сайт с небольшим количеством посетителей и небольшим набором данных. Данные изменяются исключительно одним пользователем (администратор).

Чтобы упростить ситуацию, я не хочу беспокоиться о реальной базе данных или данных XML. Я думаю о сохранении всех данных через сериализацию PHP в несколько файлов. Например, если есть несколько категорий, я буду хранить массив, содержащий Category экземпляров классов для каждой категории.

Существуют ли подводные камни при использовании PHP-сериализации в этих обстоятельствах?

Answer 1

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

Подводные камни, которые я вижу, как упоминал Йонатан:

1. Обслуживание и добавление функций.
2. Нет простого способа запросить или просмотреть данные.
3. Очень небезопасно - взгляните на "hackthissite.org". Многие из начальных примеров связаны со взломом, когда кто-то помещает данные в файлы в жестком коде.
4. Сериализация будет работать для одного массива, то есть для одной таблицы. Если вам нужно что-то сделать, например, иметь родительские категории, которые должны соответствовать другим данным, то это не сработает.

Answer 2

Подводные камни возникают при обслуживании и добавлении функций.

Это очень хороший способ обучения, но вы по достоинству оцените базы данных после уроков.

Answer 3

Я пытался реализовать сериализацию PHP для хранения данных сайта.Для тех, кто хочет сделать то же самое, вот отзыв о проекте, начатом несколько месяцев назад и сильно измененном с тех пор:

Плюсы:

• Это было очень легко загружать и сохранять данные .Мне не нужно писать SQL-запросы, оптимизировать их и т. Д. Код короче (с параметризованными SQL-запросами он может сильно возрасти).

• Для развертывания не требуется дополнительныхусилия. Нас не волнует, что поддерживается на веб-сервере : если есть только PHP без дополнительных расширений, серверов баз данных и т. Д., Сайт все равно будет работать.Sqlite - это хорошо, но установить его на некоторых серверах невозможно, и для него также требуется расширение PHP.

• Нам не нужно заботиться об обновлении сервера базы данных.или об используемом сервере базы данных (что позволяет избежать сценария, когда клиент хочет перейти с Microsoft SQL Server на Oracle и т. д.).

• Мы можем добавить больше свойств к объектамбез необходимости ломать все (как мы можем добавить другие столбцы в базу данных).

Минусы:

• Как сказал Керри в своем ответе, "нет простого способа запрашивать или просматривать данные" .Это означает, что любые дела бизнес-аналитики / статистики невозможны или требуют огромного количества работы.Кстати, некоторые базовые сценарии становятся чрезвычайно сложными.Допустим, мы храним продукты и хотим знать, сколько их продуктов.Вместо того, чтобы просто писать select count(1) from Products, в моем случае для этого нужно просто создать файл PHP, загрузить все данные, а затем подсчитать количество элементов, иногда добавляя материал вручную.

• Некоторые изменения, необходимые для реализации переноса данных , были болезненными и требовали больше работы, чем просто выполнение SQL-запроса.

В заключение Я бы порекомендовал использоватьСериализация PHP для хранения данных небольшого веб-сайта, измененного одним человеком , только если выполняются все следующие условия :

1. Контекст развертывания неизвестен иесть шансы иметь сервер, который поддерживает только базовый PHP без расширений,

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

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

Answer 4

Я бы сказал, используйте небольшую базу данных, такую ​​как sqlite, если вы не хотите настраивать полноценный db-сервер. Однако я также скажу, что сериализация массива и его сохранение в текстовом файле довольно быстрая. Мне пришлось сериализовать массив с несколькими тысячами записей (дамп из базы данных) и использовать его в качестве временной базы данных, когда наш сервер БД перестраивался в течение нескольких дней.