Стоит ли когда-нибудь хранить большие двоичные объекты в базе данных? - PullRequest
Новая
       19

Стоит ли когда-нибудь хранить большие двоичные объекты в базе данных?

4 голосов
/ 02 июня 2009

Некоторое время я работал над вставкой данных из раздутой книги Excel в базу данных SQL. Моя команда предложила сохранить резервную копию .xls, и они задаются вопросом, может ли быть хорошей идеей поместить рабочую книгу Excel в базу данных, чтобы все соответствующие данные из нашего проекта были вместе.

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

Каковы плюсы (если они есть, помимо хранения производственных данных и резервной копии в одном месте) и минусы размещения BLOB-объектов в базе данных?

Редактировать: Просто, чтобы прояснить немного дальше, хотя я даю конкретный сценарий, я намерен, чтобы этот вопрос касался в основном BLOB-объектов в целом. Но все, что я могу найти для ваших ответов, которые помогут мне в моей конкретной ситуации, конечно, приветствуется. :)

Спасибо,
Роберт


Постскриптум Для тех из вас, кто не знал, BLOB является обратным термином для "Binary Large Object"

Ответы [ 3 ]

5 голосов
/ 02 июня 2009

Как правило, я избегаю помещать BLOB-объекты в базу данных, если есть другие варианты хранения, которые стоят дешевле. Конечно, существуют веские причины для хранения больших двоичных объектов в базе данных, но я склонен проявлять осторожность и использовать FS для хранения файлов и базы данных для структур данных.

Поскольку вы используете SQL 2008, вас также может заинтересовать тип данных FileStream . Это может облегчить вам жизнь.

2 голосов
/ 02 июня 2009

Многие пакеты CMS (такие как Sharepoint) в любом случае хранят все это как BLOB.

Краткое резюме. У меня нет личного мнения, потому что мне никогда не приходилось проектировать или разрабатывать очень большие большие двоичные объекты (например, электронные таблицы) в БД. Я сохранил изображения и другие мелкие вещи.

В базе данных:

Плюсы: Предполагая, что другие данные, а также большие двоичные объекты:

  • это все в одном месте.
  • резервное копирование / восстановление связны

Минусы:

  • база данных раздувается
  • Производительность

Нет базы данных

Плюсы:

  • Нет переполнения базы данных
  • Хранится изначально

Минусы:

  • Резервное копирование / восстановление более сложное
  • Риск неработающих ссылок
1 голос
/ 03 июня 2009

Мне кажется, что при необходимости открыть электронную таблицу Excel становится сложнее, если это блоб. С другой стороны, вы не хотите, чтобы резервная электронная таблица изменялась без изменения данных, поэтому в вашем случае это может быть преимуществом. Вы также можете подумать, сколько ревизий электронной таблицы вы хотите сохранить. Нас часто просят оглянуться на необработанные входные данные от клиента, которые возвращаются на год или больше (действительно весело, когда вы получаете ежедневный файл), чтобы найти источник проблемы (или, по крайней мере, доказать, что это они, а не нас!). Если вам нужно просмотреть разные версии данных, ваш блоб должен быть в связанной таблице. Это, пожалуй, и преимущество в вашем случае, так как, как мне кажется, вам редко потребуется доступ к этим данным.

...