Pros/Cons to storing images in a DB

  • What do you think are the pros and cons in storing images in a Database?

    Is it just a realestate issue..or does it go further than that?

  • I think Im the only one in favor of putting them in the db on here. Pro's are that it's in the db, secure, gets backed up. Con's are you put more work on the server. Disk space is a wash, going to get used somewhere. We went with a split here on the site, images for articles are stored in the db, then we build/rebuild our asp pages whenever something changes.

    Andy

  • Some good threads on this:

    http://www.sqlservercentral.com/forum/topic.asp?TOPIC_ID=3356&FORUM_ID=9&CAT_ID=1&Topic_Title=Working%20with%20images&Forum_Title=General

    Another one somewhere.

    Also you have to backup the image db, which is a load. Takes backup and restore time. If you want to do this, I'd look at a separate db from your data.

    Steve Jones

    steve@dkranch.net

  • I figured one of the biggest problems had to deal with real-estate. I'm not too worried about putting a large load on my server. I have 5 instances of SQL SERVER 2000 running on different servers and desktops. Right now, only one is being utilized to it's full potential.

    So let's just say I decide to go this route. What interfaces must you use to insert and load images from the DB? Must you use ASP to insert or can you use T-SQL from the analyzer?

    I really haven't found much documentation on how to actually implement this theory. I'd like to play around with this idea. In the long run, I'll probably have an ASP/ASP. NET upload/display interface.

    Any thoughts?

  • TSQL isnt a fun way to manage it. The ADO stream (or the older chunk methods) is a lot easier and more practical. There is a bulk loader tool in the sample files that is installed with SQL. I belive if you search for stream you should find some sample code.

    Andy

  • I don't think you can do this with T-SQL easily. Of course, you could probably whip up an ADO/ASP tool in about 15 minutes.

    The biggest issue is backup and restore, IMHO. If you store in the same db, then your restore times are longer if you need them for no reason. That's why I'd say separate db.

    Steve Jones

    steve@dkranch.net

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply