Мультисерверное хранение файлов

Статус
В этой теме нельзя размещать новые ответы.
Так обычно не делается.
А как иначе?
Я себе прикинул вот какую схему:
Необходимо загрузить файл и сохранить в БД информацию о нём: размер, тип, дату загрузки и т.д. В php многое из этого можно почерпнуть из массива $_FILES, а он доступен в принявшем файл скрипте (скажем upload.php), который, в свою очередь, выполнился на принявшем файл сервере. Мне казалось что оптимально будет настроить чтобы upload.php создавал в БД строку с файлом, загонял туда информацию, а фронтенду (движку) просто отдавал id (mysql_insert_id()) файла.
Мне этот вариант кажется логичным.
Или есть пооптимальнее? Буду рад если поделитесь...)
 
Самым оптимальным для меня решением является примерно такое:
1. Фронтенд получает файл, создает о нем запись с информацией о файле - размере, времени создания и проч.
2. Фронтенд перенаправляет файл бекенду нужного сервера в сети.
3. Бекенд принимает файл, записывает, и возвращает реальный адрес до файла.

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

Если бы речь шла не о файлах, то я бы использовал XML-RPC/SOAP, т.к. с помощью этих технологий можно наладить платформонезависимое общение фронтенда с множеством бекендов, вне зависимости от используемых на них языках. Но тут файлы, и я не уверен, что через XML-RPC или SOAP можно передавать их без головной боли. :)
 
Я не считаю оптимальным хранить информацию о файлах распределенно - все-таки файловые хранилища для этого не предназначены, и использовать их как кластер БД - не самое удачное решение.
Видимо ты не так понял. В моей схеме все бэкэнды пишут в одну общую централизованную датабазу.
Просто я почему за неё зацепился: согласно ей, файл загружается сразу на контент-сервер, там же и остаётся. Так можно экономить трафик и время.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху