Thank you very much Keith, Simons, Clements, it helped me a lot! Sorry for the late reply,
olivier Le 8 oct. 2012 à 18:14, Keith Medcalf <[email protected]> a écrit : >>> Images are handled in the app: photo of products, photos of customers, etc. >>> Each client can have thousands. >>> Advise you manage images as blob in the database? or have only the URL of >>> images in the database (so the image files on the hard disk)? > >>> The first solution seems simpler, more secure. But is it slows down >>> significantly the database? Especially if the database is encrypted? > >> Using a web service is different to asking the same question about an app >> which runs on one computer. If your web server would serve the images >> straight from files on disk, I would leave the images as individual files. >> Web server software is optimised to serve many different files, caching them >> intelligently. It will do a good job of working out how to serve many >> different files in an efficient manner. > >> If you keep the image data inside the database you have to write some code >> which will extract the data and present it as an 'image/jpeg' file or >> whatever it is. This isn't too difficult but it's one more thing to go >> wrong, the server won't be able to cache those returns, and doing the >> processing (especially for an encrypted database) will require more CPU than >> just serving the images from disk. If secrecy of the images is an issue make >> sure you are serving over HTTPS not HTTP. > > The OP will also have to generate "proper" metadata and cache control when > processing a GET for the image, and also be able to respond to HEAD requests > to check for client-side and intermediate cache validation. On top of the > server overhead incurred because the underlying data is dynamic therefore > having to call into the app code and do a database dip on every HEAD and GET > request, not coding the metadata and cache control correctly will result in > mucho duplicated traffic to repeatedly tranfer the same unchanged image, and > performance will be terrible. > > In other words, the application will have to duplicate the sematics of a > filestore by manually accounting for all the processing that is already coded > into the web server to handle static files. > > I'd just store the images in files on disk and syncronize the filesystem > contents with the URLs stored in the database. Why go to all the > complication of duplicating huge swaths of code already present in the web > server and then debugging that code. Unless of course you have written web > servers before and know all the nuances that you have to deal with to > correctly respond to dynamic requests for (mostly) static content. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
