0

We can save an image with 2 way

  1. upload image in Server and save image url in Database.
  2. save directly image into database

which one is better?

Babak Naffas
  • 12,395
  • 3
  • 34
  • 49
M.Azad
  • 3,673
  • 8
  • 47
  • 77

4 Answers4

6

There's a really good paper by Microsoft Research called To Blob or Not To Blob.

Their conclusion after a large number of performance tests and analysis is this:

  • if your pictures or document are typically below 256K in size, storing them in a database VARBINARY column is more efficient

  • if your pictures or document are typically over 1 MB in size, storing them in the filesystem is more efficient (and with SQL Server 2008's FILESTREAM attribute, they're still under transactional control and part of the database)

  • in between those two, it's a bit of a toss-up depending on your use

If you decide to put your pictures into a SQL Server table, I would strongly recommend using a separate table for storing those pictures - do not store the employee foto in the employee table - keep them in a separate table. That way, the Employee table can stay lean and mean and very efficient, assuming you don't always need to select the employee foto, too, as part of your queries.

For filegroups, check out Files and Filegroup Architecture for an intro. Basically, you would either create your database with a separate filegroup for large data structures right from the beginning, or add an additional filegroup later. Let's call it "LARGE_DATA".

Now, whenever you have a new table to create which needs to store VARCHAR(MAX) or VARBINARY(MAX) columns, you can specify this file group for the large data:

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

Check out the MSDN intro on filegroups, and play around with it!

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
1

Like many questions, the ansewr is "it depends." Systems like SharePoint use option 2. Many ticket tracking systems (I know for sure Trac does this) use option 1.

Think also of any (potential) limitations. As your volume increases, are you going to be limited by the size of your database? This has particular relevance to hosted databases and applications where increasing the size of your database is much more expensive than increasing your storage allotment.

Babak Naffas
  • 12,395
  • 3
  • 34
  • 49
0

Saving the image to the server will work better for a website, given that these are incidental to your website, like per customer branding images - if you're setting up the next Flickr obviously the answer would be different :). You'd want to set up one server to act as a file server, share out the /uploaded_images directory (or whatever you name it), and set up an application variable defining the base url of uploaded images. Why is it better? Cost. File servers are dirt cheap commodity hardware. You can back up the file contents using dirt cheap commodity (even just consumer grade) backup software. And if your file server croaks and someone loses a day of uploaded images? Who cares. They just upload them again. Our database server is an enterprise cluster running on SSD SAN. Our backups and tran logs are shipped to remote sites over expensive bandwidth and maintained even on tape for x period. We use it for all the data where we need the ACID (atomicity, consistency, isolation, durability) benefits of a RDBMS. We don't use it for company logos.

Brian White
  • 1,265
  • 1
  • 10
  • 16
0

Store them in the database unless you have a good reason not to.

Storing them in the filesystem is premature optimization.

With a database you get referential integrity, you can back everything up at once, integrated security, etc.

The book SQL Anti-Patterns calls storing files in the filesystem an anti-pattern.

Neil McGuigan
  • 46,580
  • 12
  • 123
  • 152
  • Filesystems are designed for files. Databases are not. Do you store your website code in a filesystem or a database? Storing a url instead of a file doesn't impact security in the slightest. – Brian White Jul 30 '12 at 00:50
  • If you don't care about referential integrity, then you should store them in the file system. Of course, if you don't care about referential integrity, why are you using a database? – Neil McGuigan Jul 30 '12 at 01:37
  • For data. A url is data. It needs to match referential integrity - point to a real company id or category id for example. The contents of an image file will never matter to referential integrity. Images are very web tier. The simplest website is just static html files and static image files. Images are served very efficiently by web servers optimized for the task. If someone keeps changing their logo image, but keeping the same name for it, why keep updating your database with new blobs? If these aren't client images but yours, then you can always track them in subversion, etc – Brian White Jul 30 '12 at 17:56
  • Right, so when I backup my patient database and forget to backup the patient's x-rays, it's okay, because they're web-tier. LOL. – Neil McGuigan Apr 12 '13 at 06:58
  • We recently started using OpenStack. It's a fine place to store images, and you get replication built in. Our relational database still isn't a good place for it. There is one group at work that is storing images in a database, but it's just way too slow to use for anything on the site. If you are working on a smaller non-web system with a low number of concurrent users you may not have bumped into the limits here. It's not premature optimization for us. The file system is too slow for all the images we actually control, we use the Akamai CDN to serve them up. – Brian White Apr 13 '13 at 15:29