Hello. I have this question. A client of mine have had this simple asp-page that displays flash-files from a folder on their site. But now i've helped them "develop" copies of their site and they want me to build an admin-system for their banners (which can be in jpg, gif or flash format). The thing is that all the sites share database (Microsoft SQL), so what i want to do is to stuff the images/flash-files in the database rather than have them upload the same files to 7 differnet places.

 

Now to my question. How do you display a flash-movie on a page that is saved in an image field in a SQL-database?

I know how to show the images, cause the server that hosts their files have some "plugin" for that, but i have yet to find a way to read the flash-movies from the database and show them on a webpage.

 

The pages are written in classic ASP and as it is now the page that displays their banners is included in their layout. What i want is that included page to display the images and flash-movies that are saved in image fields in the database. I've seen some solutions that use like a "displayImage.asp?imageId=1". I would like something like that as well but for the flash-movies.

 

Best regards and thanks in advance, Ludvig

Hello again. Sorry i haven't replied to this for quite some time. But i DO in fact know that the images ARE stored in the database and i get the idea of storing paths for the flash files.

The thing is that my client doesn't want that. They want a single admin for all their 7 sites so they don't have to upload each file via ftp 7 times.

 

So my question still stands. How would i go about displaying a flash-file stored in an image-field in a microsoft sql database?

rallport is 100% right. It's a very bad idea to store images et al directly in a database.

 

What I suggest is create a subdomain called http://img.yourdomain.co.uk. In that away all your images are stored in one location for the 7 sites to refer to. You could even register a nondescript domain name such as ourimgserver.co.uk so you don't give the game away that the 7 sits are somehow connected.

 

Regs,

Numb

Check out the tutorial on 4guysfromrolla.com

 

http://www.4guysfromrolla.com/webtech/060100-1.shtml

 

That gives you the code to extract an image blob/binary from a MS SQL database.

 

You will just need to change lines..

 

  'Step 3: Set the ContentType to image/jpeg
 Response.ContentType = "image/jpeg"

 

..to the content/MIME Type you require

Check out the tutorial on 4guysfromrolla.com

 

http://www.4guysfromrolla.com/webtech/060100-1.shtml

 

That gives you the code to extract an image blob/binary from a MS SQL database.

 

You will just need to change lines..

 

  'Step 3: Set the ContentType to image/jpeg
 Response.ContentType = "image/jpeg"

 

..to the content/MIME Type you require

 

 

Ya may be able to do it but Its not a good way to take up database resources. I never hold image data on a db, just the file name and reference it to a img only sub domain.

 

Regs,

Numb

Ya may be able to do it but Its not a good way to take up database resources. I never hold image data on a db, just the file name and reference it to a img only sub domain.

 

Regs,

Numb

 

Yeah, but you can use HTTP caching so you're not hitting the DB all the time. Just check the last modified date in the Header.

 

Much easier (and faster) to store images in the DB from a management/backup perspective. Just backup the DB :-)

 

Also, depends on what spec server you have for the DB.

 

Mircosoft SharePoint stores all its assets in the DB, and makes it really easy to deploy/re-deploy/duplicate any site.

Thanks for the link suedeapple. I'll be sure to check it out.

And this isn't some massive multi mega super company.

It's a rather small company, so making sub domains etc is really out of the question. It's either upload stuff to 7 places or stuff them in the database.

And it's not like there's massive amounts either. It will most likely be 3-4 images or flash-files displayed on any given site at a time.

 

So thanks for the considerations (and having pro music taste! Current title: Pink Floyd - Us and Them ) ComfortablyNumb, but it's kinda out of scale for their company. I would however consider your way if it was on a much larger scale.

 

//Raszagal

It's either upload stuff to 7 places or stuff them in the database.

 

//Raszagal

 

We had a client with such a system, and several front ends located on various different hosts. Images were named to match with record IDs in the db (eg 1.jpg, 3245.png, etc). The obvious way was to just link to the images on the site they were uploaded to. So each of the several front ends pulled the images from a single site. But this was trickier because not all the records had matching images, and they might be either gif jpg or png. When it was all hosted on one server we could check whether a file existed, but it was harder to do this remotely (and would have been much slower).

 

So what we did was have the remote sites call an ASP page on the site hosting all the images... eg

 

img src="http://sitewithimages.co.uk/showimage.asp?id=3245"

 

This script looked for an image called either 3245.png, 3245.jpg or 3245.gif and showed it, else it returned a single pixel blank gif. It works fine, means client only has to update images in one central site, and avoids storing the images in a database.

Yeah, but you can use HTTP caching so you're not hitting the DB all the time. Just check the last modified date in the Header.

 

Much easier (and faster) to store images in the DB from a management/backup perspective. Just backup the DB :-)

 

Also, depends on what spec server you have for the DB.

 

Mircosoft SharePoint stores all its assets in the DB, and makes it really easy to deploy/re-deploy/duplicate any site.

 

Sorry to break it, but storing images in a database isn't easier and definitely isn't faster.

 

1. The database in most applications is the bottleneck - by storing images in it you're adding a huge amount of stress. A database should be fine tuned to return data, not blobs.

 

2. You'll eventually need to use a CDN if your site gets popular.. It will be a nightmare to transfer them.

 

3. To pull an image from the database you're adding silly amounts of processing & memory usage, when you could just simply serve the image from a web server such as nginx which is great with static files.

 

4. Backups.. How can you say it's easier? If anything it's harder - as the backup will reflect the size of your images. Let's say you have a moderate amount of uploads.. 10GB your backup will be at minimum 10GB in a text file... You'll be presented with a huge amounts of bugs and the backup would take hours to restore. It's even more worrying when you hit 1TB.

 

I recommend you store the path to the file in the database. You can then have a much more versatile caching system which won't be limited.

 

 

Do not store images in a database, you'll later regret it.