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 in VARCHAR(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.