Хранение изображений на базе данных [дубликат]

В SQL Server есть параметры для управления местом хранения больших двоичных объектов данных, они были там с момента аренды SQL2005, поэтому я не знаю, почему вы не можете хранить большие двоичные объекты данные. MOSS, например, хранит все документы, которые вы загружаете в него, в базе данных SQL.

Конечно, есть некоторые последствия для производительности, как и почти все, поэтому вы должны позаботиться о том, чтобы не получить blob, если вы не не нужно, и не включайте в индексы и т. д.

I'll try to decompose your question and address your various parts as best I can.

• SQL Server 2008 and the Filestream Type - Vinko's answer above is the best one I've seen so far. The Filestream type is the SQL Server 2008 is what you were looking for. Filestream is in version 1 so there are still some reasons why I wouldn't recommend using if for an enterprise application. As an example, my recollection is that you can't split the storage of the underlying physical files across multiple Windows UNC paths. Sooner or later that will become a pretty serious constraint for an enterprise app.

• Storing Files in the Database - In the grander scheme of things, Damien Katz's original direction was correct. Most of the big enterprise content management (ECM) players store files on the filesystem and metadata in the RDBMS. If you go even bigger and look at Amazon's S3 service, you're looking at physical files with a non-relational database backend. Unless you're measuring your files under storage in the billions, I wouldn't recommend going this route and rolling your own.

• A Bit More Detail on Files in the Database - At first glance, a lot of things speak for files in the database. One is simplicity, two is transactional integrity. Since the Windows file system cannot be enlisted in a transaction, writes that need to occur across the database and filesystem need to have transaction compensation logic built in. I didn't really see the other side of the story until I talked to DBAs. They generally don't like commingling business data and blobs (backup becomes painful) so unless you have a separate database dedicated to file storage, this option is generally not as appealing to DBAs. You're right that the database will be faster, all other things being equal. Not knowing the use case for your application, I can't say much about the caching option. Suffice it to say that in many enterprise applications, the cache hit rate on documents is just too darn low to justify caching them.

Hope this helps.

Один из Классическая причина осторожности при хранении BLOB-объектов в базах данных заключается в том, что данные будут храниться и редактироваться (изменяться) под управлением транзакций, а это означает, что СУБД должна гарантировать, что она может откатить изменения и восстановить изменения после сбоя. Обычно это делается с помощью некоторых вариаций темы журнала транзакций. Если СУБД должна записывать изменение в двоичном объекте размером 2 ГБ, она должна иметь способ определения того, что изменилось. Это может быть простое (изображение до и после) или более сложное (своего рода двоичная дельта-операция), требующее больших вычислительных затрат. Даже в этом случае иногда чистым результатом будут гигабайты данных, которые будут сохранены в журналах. Это снижает производительность системы. Существуют различные способы ограничить влияние изменений - уменьшение объема данных, проходящих через журналы, - но есть компромиссы.

Наказанием за хранение имен файлов в базе данных является то, что СУБД не имеет контроля (в общем случае ) при изменении файлов - и, следовательно, опять же, воспроизводимость данных нарушается; вы не можете гарантировать, что что-то вне СУБД не изменило данные. (Там' это очень общая версия этого аргумента - нельзя быть уверенным, что кто-то вообще не вмешивался в файлы хранилища базы данных. Но я имею в виду сохранение имени файла в базе данных со ссылкой на файл, не управляемый СУБД. Файлы, управляемые СУБД, защищены от случайного изменения непривилегированными лицами.)

Новая функциональность SQL Server кажется интересной. Я не исследовал, что он делает, поэтому не могу прокомментировать, в какой степени он избегает или ограничивает проблемы, упомянутые выше.

Новая функциональность SQL Server звучит интересно. Я не исследовал, что он делает, поэтому не могу прокомментировать, в какой степени он избегает или ограничивает проблемы, упомянутые выше.

Новая функциональность SQL Server звучит интересно. Я не исследовал, что он делает, поэтому не могу прокомментировать, в какой степени он избегает или ограничивает проблемы, упомянутые выше.

There are options within SQL Server to manage where it stores large blobs of data, these have been in there since at lease SQL2005 so I don't know why you couldn't store large BLOBs of data. MOSS for instance stores all of the documents you upload to it in a SQL database.

There are of course some performance implications, as with just about anything, so you should take care that you don't retreive the blob if you don't need it, and don't include it in indexes etc.