May 10, 2002 at 11:24 am
Is is better to store images in SQL2000 or to just use a string pointing to the db and have the actual images reside on the web server? I realize that maintenance can be somewhat easier by using SQL but which is more efficient?
thanks-
chris
</cm>
</cm>
May 10, 2002 at 11:54 am
Storing images onto file system would be better efficient. You would find managing the files better if stored into database. But are the best person to judge what should be ideal in your situation looking at the cost-benefit ratio.
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 10, 2002 at 12:33 pm
I like storing them in the db. If you do a search on the site you'll find several threads that cover the pros/cons in detail.
Andy
May 10, 2002 at 1:26 pm
I had avoided storing into DB only for 1 reason. As I cannot show the image and the related text on the same web page. This is because, in ASP to show the image i have to set the MIME type to image/gif or image/jpeg before I send the content for image. And then later when I want to show the text relating to it, I am unable to change the MIME type as ASP allows setting the mime type only once.
Whats the alternative to this?
quote:
I like storing them in the db. If you do a search on the site you'll find several threads that cover the pros/cons in detail.Andy
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 10, 2002 at 1:26 pm
I had avoided storing into DB only for 1 reason. As I cannot show the image and the related text on the same web page. This is because, in ASP to show the image i have to set the MIME type to image/gif or image/jpeg before I send the content for image. And then later when I want to show the text relating to it, I am unable to change the MIME type as ASP allows setting the mime type only once.
Whats the alternative to this?
quote:
I like storing them in the db. If you do a search on the site you'll find several threads that cover the pros/cons in detail.Andy
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 10, 2002 at 9:28 pm
disageee with Andy on this one, but if you choose the DB, make it a separate DB from the data. Easier to backup and manage. Like the filesystem since you can then just use IIS to yank the image back.
What's the big deal with setting the MIME type. You do it once in code and the computer then handles it.
Steve Jones
May 11, 2002 at 4:51 am
How do you set contenttype for one response object? It can be sent only once. If you are able to do it twice on the same page, pls let me know how did you manage to do it.
If you do have a ready example, pls send.
quote:
disageee with Andy on this one, but if you choose the DB, make it a separate DB from the data. Easier to backup and manage. Like the filesystem since you can then just use IIS to yank the image back.What's the big deal with setting the MIME type. You do it once in code and the computer then handles it.
Steve Jones
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 11, 2002 at 8:03 am
You msy indeed have to set it twice, but you only do that when you code. The time to set this in code is pretty small. You could also write a function that takes your object as a parameter, sets the type and sends the object.
Steve Jones
May 11, 2002 at 8:12 am
Another point is that you if you use an ADO stream to retrieve it, you can push it directly to the response object without having to write it to disk first. Seems handy to me.
Andy
May 11, 2002 at 8:24 am
Sorry Steve, but I think you are missing out somewhere. RESPONSE object is ASP can set its contenttype only once. I have not tried it by using the ADO Streams as suggested by Andy.
quote:
You msy indeed have to set it twice, but you only do that when you code. The time to set this in code is pretty small. You could also write a function that takes your object as a parameter, sets the type and sends the object.Steve Jones
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 11, 2002 at 10:15 am
Andy is right with using the ADO stream to handle it and is almost as efficient as storing on the drive. However when deciding where to place (DB or filesystem) here is what I consider.
For applications that call the DB directly since you already have a connection to the database and the app can pull from it directly on the stream. And you do not have to grant any filesystem permissions to get. Thus I would go with the DB storage.
However with asp I run with the filesystem approach and here is the major reason why. WHen I setup my SQL server it is seperate from IIS server and I link the 2 together via a 100MB hub between them while they have connections to the main network. When I want to access data on the SQL server from ASP am going across a link thus I really want to get the connection to the SQL server cleared as quickly as possible so other connections can access it and the personal bandwidth is open as much as possible. By storing the image in the DB I thus increase the amount of data being pushed across the link and depending on the image size this can get quite large and consume a lot of bandwidth. By using pointers instead I can move less bites across the personal network and the files are on IIS so they will pickup nicely. The only reason anyone was able to give me to put in the DB was for my App situation in addition to the web but I include on those apps a Web control and have it pull the image from IIS which really isn't that bad as no special permissions have had to been granted in that case. Also as for backups if all you do is SQL backups then shame on you, your web server contents should be backedup regularly as well.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 11, 2002 at 10:25 am
i too was on the side of storing images into database. But the only reason i had to forgo that option was the response object in asp. I was unable to display the image on the ASP page as I could not change the MIME type in between.
Also what would you consider for storing other types of files like doc,xls,pdf?
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 11, 2002 at 10:45 am
I would continue with the same statement I made before.
DB if App hitting DB direct and no IIS server involved with same data not in DB.
FileSystem if ASP based to reduce trip time and data movement between SQL and IIS.
FileSystem for an App if you have an ASP website where you access the same data and can ustilize that and not double store the data.
Although with some file types you will have to drop to the clients local side Hard Drive and open once done.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 11, 2002 at 10:52 am
What if, I have the IIS and SQL Server on the same machine. That would avoid the trips over the hubs. Then what would have been your choice?
quote:
I would continue with the same statement I made before.DB if App hitting DB direct and no IIS server involved with same data not in DB.
FileSystem if ASP based to reduce trip time and data movement between SQL and IIS.
FileSystem for an App if you have an ASP website where you access the same data and can ustilize that and not double store the data.
Although with some file types you will have to drop to the clients local side Hard Drive and open once done.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 11, 2002 at 10:55 am
In that case it really would be up to you. Sorry no help there but this runs into how much trouble is it to do the DB store or should you just use pointers. In that case I would go with FileSystem personally as is quite a bit easier to implement and your concerns are just that how easy is it to do.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply