|  | | How much space can I save by using DBPix ? | There are several ways in which you can save space by using DBPix.
How much you can gain depends very much on the existing sitution, the source image resolution and the needs of the application.
The topics below can each give very large reductions of space in some cases.
Image Optimization
Preparing optimized images can save dramatic amounts of space (both for storage in tables or external files), particularly if your source images are from high resoltion scanners or cameras. The resolution of these images is typically much higher than might be needed on screen (unless you need the facility to zoom right-in to the orinal detail level). Storing the image at a higher resolution than necessary not only results in a (potentially very large) waste of storage space, but also reduces performance, may consume additional bandwidth and system resources, and may actually result in a lower quality visible image when displayed at screen resolution. This is due to the resizing algorithms used to display images at a lower resolution on screen (very fast, but low quality) vs those available when the image is actually stored (high quality, but a little slower).
Store raw binary, not Embedded or Linked OLE Objects
OLE Linking & Embedding is a technique used by Microsoft Access to store 'Objects' in database tables.The technique relies on the associated external application to store, present and edit the data.
In some cases an additional uncompressed 'preview' image is also saved in the table (even when linking). This preview image is used for faster display of the data, or when the server application isn't available. This can cause a massive overhead. If you're storing jpeg images the uncompressed preview can be ten or twenty times the actual image size, causing the size of the database to rocket.
You can avoid this, as well as some other potential difficulties that you may experience with OLE Linking or Embedding, by storing only the raw image data in the table. In this way the images should occupy no more than they would as files on disk (or even a little less, due to table granularity vs clusterize).
This assumes that a suitable compacting schedule is observed according to the frequency of deletes and edits.
| |
|
|
Home
Tutorials
