Добрый день. Нужны советы по проектированию файлового хранилища.
Задача: Загрузка различного типа файлов. Своего рода, очень упрощенный аналог яндекс диска с переходом по директориям.
Как лучше хранить данные(название, вес, дата загрузки и т.п.) загруженного файла?
Есть несколько вариантов: 1) Хранить данные всех файлов в директории, в одном конфиге json. (Например, в одной папке 10 файлов и 1 json в котором хранятся все данные этих 10 файлов) 2) Хранить данные для каждого файла в отдельном json. (10 файлов = 10 json) 3) Хранить данные о файле в БД.
Нужно так же учитывать, что файлы в одну директорию могут загружаться разными пользователями одновременно. В таком случае вариант 1 по всей видимости отпадает.
Возможно все 3 варианта полный бред, если у кого-то есть мысли, опыт в этом, поделитесь, пожалуйста.
Если работать с файлами, то возникают организационные вопросы к тому как организовывать копирование файлов и папок в этом случае. Плюс когда метаданные (а это и есть название, вес, дата итд) в базе, то по сути все равно где сам файл (на той же физической машине или загружен куда-то в облако типа Amazon S3).
Еще база упростит собирание метаданных по папке, типу файлов, владельцев файлов, хитрые фильтрации и сортировки просто через запросы БД. Если оперировать чисто файлами, то их нужно будет или каждый раз считывать или как-то кешировать в памяти, пробегаться по всем чтобы собрать данные.
На этот вопрос у меня нет устойчивого мнения. Я бы советовал брать ту базу с которой есть опыт или по которой есть кому подсказать. Документная типа монги сработает, sqlite сработает (при это будет проста в поддержании), postgresql тоже сработает.
Добрый день. Если SQL, то правильной ли будет связь таблиц one to many? Где one - это пользователь, а many - файлы пользователя.
Есть 2 таблицы: Users и Files
Выглядит примерно так: Users id email password Files name path user_id
Получается, одна связанная таблица Files для всех пользователей. По-моему, это не правильно. Наверное, лучше, если таблицы с метаданными файлов будут создаваться для каждого пользователя отдельно. А в таблице юзер просто хранить ссылку на уникальное имя этой таблицы.
Но мне сложно предположить какой из этих вариантов может быть производительнее. Во втором варианте получается, как таковой связи нет. Будет дополнительный запрос к базе.
Или это все не правильно и нужно как-то по другому это организовать.
Сразу предупрежу что я не профи в sql-е (но кой-что пишу-дизайню с помощью ИИ и гугления).
Предложенная структура достаточно хороша. Про производительность не стоит думать: она будет иметь копеечную цену, ты больше потратишь времени-усилий думая про нее чем экономля время. Тебе важнее придумать такую модель-структуру таблиц чтобы они хорошо отражали твою доменную модель. Поэотому вопрос: какие аспекты еще нужно реализовать в системе? Доступ по правам? Иерархии? Папки? Чем полнее список, тем больше шансов что придуманная сегодня структура будет переиспользоваться и не потребует сложных изменений потом. Но пока что то что описано - достаточно хорошо.
Кстати. Крайне рекомендую “поговорить” с современными ИИ (вернее LLM Large Language Model) типа Claude или ChatGPT. Они отлично помогают разобраться с задачами типа той что стоит перед тобой. Вот тут можно попробовать бесплатно claude https://claude.ai (но объем запросов ограничен). У chatgpt тоже должна быть бесплатная версия, но у меня ссылки нет. Плюс есть мой бот в телеграмме Telegram: Contact @experai_bot с широким бесплатным доступом (но только к версии ChatGPT3.5, для продвинутых версий нужно платить).