Hi Frankie,
I cannot comment on what is the best practice, but as part of my
business I have a up and running application that does exactly what you
want.
I do not store the images in the DB, but instead store them on the file
system as you mentioned. The db stores the file location and some hash
(e.g size of image) information.
The client is given a list of the images from the db including the hash
information. The client can then download when required each image (as
part of a background thread if connection is slow) to the client and
cache there. It only needs to download the image if the hash
information changes (i.e. it has been updated on the server). This
solution allows for you to seperate the DB from image retrieval (they
could be on seperate machines if required). I used a webservice to
provide the images in question. I used this method as my client server
app can work disconnected, so may not have access to the db all the
time.
Note that the images can also be uploaded by the client using the same
principle.
Hope this helps you decide.
Anthoney
www.nowpromote.com.au
Frankie wrote:
Using SQL Server 2005 and .NET 2.0; I'm creating a Windows Forms application
that will need to display photos of people, along with a bunch of
information about each person.
In a Web application, there is a generally accepted "best practice" of
storing only a string (the path to the .jpg file name), with the actual file
stored in an NTFS folder (and not in the database).
What's the standard practice for Windows Forms applications? Is it the same
as for Web Forms apps?
My Windows Forms app will be a basic 2-tier client/server application - with
the need to serve up the photos+data from the central server, plus enable
users to upload photos.
Thanks.
