views:

260

answers:

5

I am currently working on an Paint-like WPF application and now stand before the problem how I enable my users to save the created images. Normally I would just save them to disk but in this application I have the requirement to later enable the user to create bigger "images" out of the already created ones. This would still be no problem with a normal filesystem approach but the user should also be able to search images by specific properties like categories/tags etc. and that would be difficult with a normal filesystem approach.

So I thought of some options I have for realizing what I want and now would like to know what you think of the approaches or if you even know a better one. The approaches are:

  • Saving images in an internal database of the application (via SQLite or something similar)
  • Saving images as normal files in the filesystem and keep an database in the application to reference these images (what happens if images were deleted by the user?)
  • Saving images as normal files in the filesystem without extra database in the app (hard to filter them by category etc.)

Thanks!

+1  A: 

SQLITE will be a good choice I feel. Version 3 onward BLOB is fully supported, so you can think of SQLITE.

Kangkan
+1  A: 

Many programs (i.e. Aperture, Lightroom, Expression Media to name a few) store their images to disk and then maintain a metadata cache in a database. This seems like the most sensible approach for your application.

David Pfeffer
+1  A: 

You can save files to the filesystem and save or read metadata directly. This feature is also available to the user outside of your application in Windows 7/Vista... I think it's called Image tags. You would have to parse XML.

Good example: http://johndyer.name/post/2006/09/01/Quick-C-Vista-Photo-Tag-Reader.aspx

masenkablast
A: 

I'd go for the second approach and use the FileSystemWatcher to track changes while the program is running and start a sync during the startup to track changes since the last time the app was run.

SqlLite or SQL Compact Editio are both good choices for a local data base to track the metadata.

Obalix
FileSystemWatcher does have some limitations when large numbers of files are added/removed at the same time, though if only one or two files are being added/removed at a time it should be OK.
ChrisF
A: 

It's certainly possible to store the image in a database. You can actually store the image stream as it would be saved to file to save space. When reading out you simply uncompress using the stream reader functionality.

This doesn't have the problems of the other two solutions (coping with deleting files, finding the files by category).

You could save to files using the filesystem by creating folders and subfolders based on your categories, but that doesn't allow you the flexibility of having more than one category per file.

ChrisF