Как организовать файловую структуру как альтернативу MySQL?
Разрабатываю сайт для личного пользования. Захотелось попробовать сделать его без использования БД MySQL, да и вообще без каких-либо БД, то есть на файлах.
Сразу же возник вопрос об правильно организации данных на сайте.
Итак, как я себе это представляю.
1. users.file хранит основную информацию о пользователях (логины, пассы, etc...).
2. news.file хранит информацию об новостях (заголовки, описания, кто оставил новость, etc...).
3. posts.file хранит только ответы, т.е ответы на любые новости/темы и так далее
Может быть знающие люди посоветуют более удачный вариант организации файловой структуры?
На сайте должна быть регистрация, авторизация, профиля, личные сообщения, новости, форум, возможность ответа на это - это самое основное.
Или же все таки не париться и использовать MySQL?
То что вам нужно — sqlite. Это sql-база данных состоящая из одного файла. В коде загружаете как обычный файл, а работаете как с SQL. Скорее всего вы ищете именно это.
В противном случае используйте любой другой популярный формат хранения данных: xml или json. Но учтите, что рано или поздно вы столкнетесь со всеми детскими болезнями баз данных. Подобный проект как учебный очень полезен, как рабочее решение — нет.
UPD. На SQLite можно сделать cms для небольшого сайта или даже магазина, это удобнее, проще и иногда надежнее. Так что в продакшене использовать такое решение можно, оно отвечает стандартам и имеет развитую инфраструктуру. Но под нагрузкой или на bigdata придется мигрировать на полноценную СУБД, так как sqlite целиком размещается в памяти.
Вам больше заняться нечем? Если хотите, то попробуйте, через N времени поймете что идея ужасная и сами придете к мысли что нужно все переделать на нормальное хранилище.
@MrGruffi сложности будут увеличиваться пропорционально размеру данных которые вы храните. Пока у вас одна новость и 5 комментариев к ней все окей. Суть файлов такова, что вам потребуется сначала загружать их в память, а потом делать из них выборки самостоятельно. В один момент данных станет больше чем памяти и все умрет.
Дисковые операции для сайта - самые дорогие и на них будет тратиться огромное кол-во ресурсов.
Добавим к этому что это ужасный велосипед который имеет право на жизнь только в целях экспериментов.
Как вывод хочу сказать, что если вы не понимаете почему это плохо, то, наверно, вы должны попробовать это сделать и научиться на своих ошибках.
К слову добавлю, что на одном очень большом проекте я использовал подобный кэш, тогда массив данных скидывался прямо в php файлы через var_export и потом подключался простым include. Php файлы при этом засасывались в акселератор и накладные расходы были крайне малыми, но эта схема работает когда структура этих данных меняется крайне редко, раз в месяц/раз в год.
Помню такую старую мобильную CMS на файлах как PCMS и еще одну от разработчиков RotorCMS. Все было на файлах и весьма стабильно работало с регистрацией, форумами, чатами, новостями и онлайн-играми
Так вот они, дауншифтеры... добрались и до ИТ. Следующий шаг - сайты без apache/nginx =)
По теме - взрослейте, пожалуйста. В мире куча нерешенных проблем, а эту уже решили использованием баз данных. Возьмите существующую проблемку и решайте, будет интересно!
