Paxdo Presse wrote: > The context: > - Web application > - Billing application > - Sqlite with WAL mode > - The database is shared among many clients. > > 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
But how do you get the images out of the database? Assuming that the images are to be displayed on some web pages, if you have the images in the file system where they are directly accessible by the web server, you can generate pages containing images like this: <p>Look at this cool image: <img src="/files/img1234.jpg"></p> But if the images are stored _only_ in the database, you would need some separate script to retrieve them: <p>Look at this cool image: <img src="/cgi/retrieve_img?id=1234"></p> If the images are mostly read-only (so that you don't actually need the database management functions for them), the second solutions seems simpler. So far. > more secure. If clients are not allowed to see other clients' images, then you need that script anyway to do access checks. > But is it slows down significantly the database? Too much image data certainly will blow out the page cache. If you store the images in a table that is in a separate database file that just gets ATTACHed to the main database, the two page caches will not affect each other. > Especially if the database is encrypted? An encrypted database will not be slower than encrypted files. If the images do not need to be encrypted, you can use a separate database file that isn't encrypted. Regards, Clemens _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
