Версии Я бегу (в основном последнее из всего):
PHP: 5.3.1
MySQL: 5.1.41
Apache: 2.2.14
ОС: CentOS (последняя версия)
Вот ситуация.
У меня есть тысячи очень важных документов: от клиентских контрактов до голосовых подписей (записи авторизации клиента для контрактов), с файлами, включая, но не ограничиваясь, jpg, gif, png, tiff, doc, docx, xls, wav, mp3 , pdf и т. д.
Все эти документы в настоящее время хранятся на нескольких серверах, включая Windows 32 bit, CentOS и Mac и другие. Некоторые файлы также хранятся на настольных компьютерах и ноутбуках сотрудников, а некоторые из них по-прежнему являются печатными копиями, хранящимися в сотнях ящиков и картотеках.
Теперь, поскольку клиенты или юристы могут требовать подтверждения контрактов в любое время, моя компания должна иметь возможность эффективно искать и находить правильный документ (ы), по этой причине ВСЕ эти файлы должны быть оцифрованы (если они еще не указаны) и коррелированы в какой-то порядок для поиска и доступа.
Как программист, я создал полный инструмент управления отношениями с клиентами, который использует вся компания. Это включает в себя управление профилями клиентов, инструменты заказа и отслеживания заданий, модули создания и управления работой / продажами и т. Д., И в настоящий момент любой файл, который необходим на уровне профиля клиента (лицензия на драйверы, полномочия по кредиту и т. Д.) Или на работу / уровень продаж (контракты, голосовые подписи и т. д.) могут быть загружены на сервер и расположены в структуре иерархии родителей / дочерних элементов, как и проводник Windows или любая другая типичная модель управления файлами.
Структура выглядит как таковая:
водительские права
| – Общение
voice_signatures
| – Охота и рыбалка
| – Охота и рыбалка
контракты
Таким образом, файлы uplaoded с использованием PHP и Apache и хранятся в файловой системе ОС. Во время загрузки определенная информация о файле (файлах) хранится в базе данных MySQL. Часть сохраненной информации:
ТАБЛИЦА: FileUploads
FILEID
CustomerID (идентификатор клиента, к которому принадлежит файл, все они имеют это.)
JobID / SaleID (идентификатор связанного с работой / продажей, если таковой имеется).
Размер файла
Тип файла
UploadedDateTime
Загружено пользователем
FilePath (путь каталога, в котором хранится файл.)
FileName (текущее имя файла загруженного файла, комбинация CustomerID и JobID / SaleID, если применимо).
Описание файла
OriginalFileName (исходное имя исходного файла при загрузке, включая расширение).
Итак, как вы можете видеть, файл связан с базой данных по имени файла. Когда я хочу предоставить пользователям файлы для загрузки для пользователя, все, что мне нужно сделать, это «SELECT * FROM FileUploads WHERE CustomerID = 123 OR JobID = 2345;» и это выведет все необходимые мне данные файла, а с FilePath и FileName я могу предоставить ссылку для загрузки.
http … server / FilePath / FileName
С этим методом существует ряд проблем:
и т. д. и т. д. Существует так много причин, некоторые из которых описаны здесь: http://www.dreamwerx.net/site/article01 . Также здесь есть интересная статья: sietch.net/ViewNewsItem.aspx?NewsItemID=124.
Итак, после долгих исследований я решил, что собираюсь хранить ВСЕ эти файлы в базе данных, как BLOB или LONGBLOB, но до сих пор есть много соображений.
Я знаю, что сохранение их в базе данных является жизнеспособным вариантом, однако есть несколько способов их хранения. Я также знаю, что хранить их – это одно; корреляция и доступ к ним управляемым способом – это совсем другое.
Статья, представленная по этой ссылке: dreamwerx.net/site/article01 описывает способ разделения загруженных двоичных файлов на куски 64kb и хранения каждого фрагмента с помощью FileID, а затем потоковой передачи фактического двоичного файла клиенту с использованием заголовков. Это действительно классная идея, поскольку она облегчает предварительное заполнение памяти серверов; вместо того, чтобы загружать весь 100-мегабайтный файл в ОЗУ и затем отправлять его клиенту, он делает это 64 кбайт за раз. Я пробовал это (и обновил его скрипты), и это полностью успешно, в очень небольшом кадре тестирования.
Поэтому, если вы согласны с тем, что этот метод является жизнеспособным, стабильным и надежным долгосрочным вариантом для хранения умеренно больших файлов (1 килобайт в пару сотен мегабайт) и большого количества этих файлов, дайте мне знать, какие другие соображения или идеи у вас есть ,
Кроме того, я рассматриваю возможность получения текущего PHP-скрипта «Управление файлами», который предоставляет интерфейс для управления файлами, хранящимися в Файловой системе, и преобразования его для управления файлами, хранящимися в базе данных. Если есть какое-либо программное обеспечение, которое делает это, сообщите мне.
Наверное, есть много вопросов, которые я мог бы задать, и вся информация там есть, поэтому, пожалуйста, обсудите все аспекты этого, и мы можем передавать идеи туда и обратно и преподавать друг другу.
Ура,
Quantico773
Я работаю над большой программной системой, которая сделала оба механизма для хранения вложений и другого контента. Первая итерация системы хранила все данные в BLOB в БД. Я проклял его в то время. Как программист, я мог писать боковые скрипты, чтобы немедленно работать с данными и изменять их, когда захочу.
Продвигайтесь около 10 лет, и я все еще управляю одним и тем же программным обеспечением, но архитектура изменилась, и он был написан с указателями файловой системы. Я проклинаю его сейчас и желаю, чтобы он вернулся в БД. У меня есть дополнительное преимущество в течение нескольких лет, и, работая над этим приложением в гораздо большей степени во многих более и более крупных ситуациях, я чувствую, что мое мнение сейчас лучше образовано. Продвижение или миграция системы приложения требует обширного сценария и копирования миллионов файлов. Однажды мы изменили ОС, и у всех указателей файлов был неправильный разделитель каталогов, или имя сервера изменилось там, где находился файл, и нам пришлось писать и планировать простые инструкции SQL-обновления с администратором базы данных в выходные, чтобы исправить. Другим является то, что записи файловой системы и БД не синхронизированы, почему неясно, но после тысяч дней работы иногда не транзакционные системы (файловая система и БД не разделяют транзакционные контексты) просто перестают синхронизироваться. Иногда файлы загадочно пропадают.
Когда все это было в БД, миграция или продвижение среды были вопросом дампа и импорта БД. Изменения в строке могут быть правильно проверены, все в синхронизации и журналы могут быть воспроизведены до момента времени, если это необходимо. Конечно, БД становится большим, но это 2011 год, и этот материал просто не является проблемой для баз данных.
Для чего у нас были некоторые подобные проблемы с большими буферами данных при потоковой передаче некоторых данных, но А) мы могли бы накачивать данные в байтовых буферах с помощью Input | OutputStreams в JDBC и B) при использовании других инструментов, мы написали хранимую процедуру который будет блокировать BLOB в временную таблицу и итеративно обслуживать куски из таблицы temp. Прекрасно работает.
Меня не волнует, какая техническая причина не помещать этот материал в БД, но управлять им проще в консолидированном местоположении, я мог бы удвоить и утроить аппаратное или сетевое БД за время, потраченное консультантами и клиентами за короткий промежуток времени управляя разрозненными файлами.
Обновление: легко комментируйте, они просто высказывают свое мнение по этому вопросу.