当我将图像数据库用于我的 asp.net Web 应用程序时,我发现了两种方法!第一种方法是使用“图像”数据类型,第二种是将图像转换为 base64 字符串并存储在“字节”数据类型中。
我想知道哪种方法在过程中更好,为什么?
当我将图像数据库用于我的 asp.net Web 应用程序时,我发现了两种方法!第一种方法是使用“图像”数据类型,第二种是将图像转换为 base64 字符串并存储在“字节”数据类型中。
我想知道哪种方法在过程中更好,为什么?
Image
type is deprecated so is not an option. There is no byte
type in SQL Server, there is a type called tinyint
which is equivalent to a byte
type but I'm pretty sure that's not what you're asking.
So here is your actual question, corrected of wrong terminology:
When I use images database for my asp.net web application , i found two methods ! First method is using
VARBINARY(max)
data type , second is convert image to base64 string and store inVARCHAR(max)
data type.
Base64 encoding adds significant size to binary data, it converts 3 octets into 4 octets, so it adds 33% overhead. That is real estate consumed in your storage (be it database or file).
However a web application will serve media files overwhelmingly as base64 encoded responses. Having the file already encoded in storage saves CPU on the web server as it can stream the storage content directly, w/o going through base64 encoding. Not that base64 encoding is expensive (is very cheap and very much cache friendly) when done properly, using streaming semantics.
So choose your poison: save binary content for smaller disk space used, or take the 33% size penalty for faster response write and less CPU on your web tier.
For an example of properly storing and serving media files from the database see Download and Upload images from aSP.Net
As for the neverending discussion about the storage be database or file system, I point you toward To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem? and its conclusion:
The study indicates that if objects are larger than one megabyte on average, NTFS has a clear advantage over SQL Server. If the objects are under 256 kilobytes, the database has a clear advantage. Inside this range, it depends on how write intensive the workload is.
This study doe snot consider the administrative problems of an out-of database storage (consistent backup-restore, failover) but those kind of problems are only discussed in v2 of products.