Храня Документы как Блобы в Базе данных - Какие-либо недостатки?
var x={}
var propName = 'value'
var get = Function("return this['" + propName + "']")
var set = Function("newValue", "this['" + propName + "'] = newValue")
var handler = { 'get': get, 'set': set, enumerable: true, configurable: true }
Object.defineProperty(x, propName, handler)
это работает для меня
7 ответов
Когда Ваш DB станет больше и больше, станет более трудно скопировать. Восстановление резервного копирования таблицы с более чем 100 ГБ данных не является чем-то, что делает Вас счастливыми.
Другая вещь, которые добираются, состоит в том, что все функции управления таблицей становятся медленнее и медленнее, когда набор данных растет.
, Но это может быть преодолено путем создания таблицы данных просто содержать 2 поля: идентификатор и BLOB.
данные Получения (первичным ключом), вероятно, только станут проблемой еще долго после того, как Вы врежетесь в стену с поддержкой набора данных.
Основной недостаток, который я часто слышу об использовании блобов, - то, что выше определенного размера файловая система намного более эффективна при хранении и получении больших файлов. Это кажется, что Вы уже приняли это для учета списком требований.
существует хорошая ссылка (PDF) здесь , который покрывает за и против блобов.
На основе моего опыта некоторые проблемы были:
-
скорость по сравнению с наличием файлов в файловой системе.
-
кэширование. IMO веб-сервер сделает лучшее задание кэширования статического содержания. DB сделает хорошее задание также, но если DB также вручает все виды других запросов, не ожидайте, что те большие документы останутся кэшируемыми долгое время. По существу необходимо передать файлы дважды. Однажды с DB на веб-сервер, и затем веб-сервера клиенту.
-
Ограничения памяти. В моем последнем задании мы имели 40 МБ PDF в базе данных и продолжали получать Java OutOfMemoryErrors в файле журнала. Мы в конечном счете поняли, что все 80 МБ, в которых PDF был считан в "кучу" не только однажды, но и ДВАЖДЫ благодаря установке, в спящем режиме ORM (если объект изменяем, это делает копию для редактирования в памяти). Как только PDF был передан потоком назад пользователю, "куча" была очищена, но это имело шумный успех для всасывания 80 МБ из "кучи" сразу только для потоковой передачи документа. Знайте свой код и как память используется!
Ваш веб-сервер должен быть в состоянии обработать большинство Ваших проблем безопасности, но если документы являются маленькими, и DB уже не является объектом большой загрузки, то я действительно не вижу большую проблему с наличием их в DB.
Этот статья охватывает большинство проблем. Если Вы используете SQL Server 2008, проверяете использование нового типа FILESTREAM, как обсуждено Paul Randal здесь .
Это зависит от databasetype. Oracle или SQLServer? Знайте об одном недостатке - восстановление единого документа.
Извините - ответ, который я предложил, был основан на SQL Server, таким образом, часть обслуживания не является соответствующей. Но файловый ввод-вывод выполняется на аппаратном уровне, и любая база данных добавляет дополнительные шаги обработки.
база данных наложит дополнительные издержки при получении документа. Когда файл находится на диске, Вы только как медленные или с такой скоростью, как ввод-вывод на сервере. Конечно, необходимо управлять meta в базе данных, но в конце Вы хотите UNC файла и указываете на пользователя на источник и уходите с дороги.
С точки зрения обслуживания и администрирования Вы ограничите себя SAN при контакте с SQL Server MS. Решения как Documentum проявляют другой подход с простым устройством хранения данных на диске, и позволяет Вам реализовывать решение для устройства хранения данных, как Вы считаете целесообразным.
РЕДАКТИРОВАНИЕ
Позволило мне разъяснить свой оператор - с SQL Server, Вы ограничили опции при превышении емкости физического хранилища поля. Это - на самом деле одни из больших слабых мест Sharepoint, что Вы не в состоянии просто присоединить любой тип сетевого устройства хранения данных.
Я только начал исследовать FILESTREAMing в SQL Server 2008 для больших двоичных объектов и столкнулся с ОГРОМНЫМ ограничением (IMO) - -это работает только со встроенной безопасностью. Если вы не используете аутентификацию Windows для подключения к серверу БД, вы не сможете читать / записывать большие двоичные объекты. Многие среды приложений не могут использовать проверку подлинности Windows. Конечно, не в гетерогенных средах.
Должно существовать лучшее решение для хранения больших двоичных объектов. Каковы лучшие практики?