1

When I use images database for my asp.net web application , i found two methods ! First method is using "Image" data type , second is convert image to base64 string and store in "byte" data type .

I want to know which method is better in process and why ?

zey
  • 5,939
  • 14
  • 56
  • 110
  • 3
    I've never found a compelling argument as to why actually storing the images *in* the database is any better than storing them on the filesystem (they are *files*, after all), and storing the path in the DB. Sometimes I think people just like to make things complicated. – Jonathon Reinhart Mar 21 '13 at 05:00
  • 1
    It's hard to say what's best without knowing what are you doing? – Jacob Seleznev Mar 21 '13 at 05:03
  • 1
    You may also find this link useful [Storing images](http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay) – Jacob Seleznev Mar 21 '13 at 05:06
  • @Jacob , I just upload image , save to db and show to page . – zey Mar 21 '13 at 05:08
  • @JacobSeleznev Thanks for that link. I'm not surprised that it's been closed, but there is a lot of good information there. – Jonathon Reinhart Mar 21 '13 at 05:09

1 Answers1

1

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.

Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569