Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
salmontres
Starting Member
1 Post |
 Posted - 2011-12-05 : 16:16:12
|
| Hi everyone,I've got a server running that has to load a handful of images per hour. Loading the images isn't very taxing, but depending on the virtual website that loads the image, it must be rescaled to match the intended layout of the website. This is what's taxing on my servers. Every time the image is loaded, it has to be rescaled.Essentially, what I want to write is a 'smart' cache, which will hold the most popular 20 GB's of the last requested pictures and files. Everything on the server side is currently written in Java, and I wanted to know if I should simply continue with Java to implement this cache, or if SQL was designed for this. If SQL has tools that would easily implement this, I wouldn't mind taking some time to learn the language now, as I know it would be helpful down the road.Any feeback/pointers would be greatly appreciated! |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2011-12-06 : 15:57:44
|
| In my opinion, sql server is not the tool for this. Images can certainly be stored as binary data in sql tables but would still need to be steamed out and re-packaged as .jpg or whatever the file format. Having said that sql server is great for storing file attributes including the location path of the actual image, the scaling, the image identifier, the popularity of the image/scale, etc. So in a way sql server (along with your java middle tier) could act as your image cache manager. For instance your java code could pass an image identifier and scale to a stored procedure which would return the location of the image scaled as needed. You would just need to keep the image folder(s) in sync with image meta data.Be One with the OptimizerTG |
 |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2011-12-06 : 16:21:26
|
| The problem with not storing the files inside the database is how to make sure your recovery point of a database is the same recovery point as the file system. It's quite the challenge. We've stored the files inside the database where having everything in sync is critical in the case of a database recovery. If you can afford some deltas between the database and the file system, then I'd say only store the path and other file attributes inside the database as TG mentioned.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog |
|
|
|
|
|
|
|
|
Creating a server cache