Re: Ideas on storing and retriving files in a Windows Application

From: William Ryan eMVP (dotnetguru_at_comcast.nospam.net)
Date: 08/17/04 

Date: Tue, 17 Aug 2004 19:36:07 -0400

Ken:

This is probably one of those areas where people on both ends of the
spectrum have some pretty strong feelings - and there's no real way to prove
who's 'right' or 'wrong'. On the side of storing things in the db you have a
few pretty straightforward plusses - 1) All of the data is self contained
in the database so you don't have to worry about people moving/deleting
files etc. 2) Because it is stored in a relational database, getting the
information out of the database is pretty straightforward and while reading
blobs takes some minor modifications other than just using SELECT blah FROM
Whatever - it's still fairly straightforward. I know a lot of folks
discount this latter part as being more purist than practical, I think it's
definitely an important thing to consider. (FYI, I seem to recall reading
that Longhorn is going to implement Searches of the file system via a
relational database which depending on your perspective is validation of
it's practicality and usefulness or proof that it's an overly complex
overengineered solutino). I think there are a few others but they can
probably all be rolled into one big one - namely you are treating the file
information in the same manner as you are other data in the application so
it provides a clean logical fit and you can handle backup/restore/security
in the same way.

On the other hand, you have performance. The internet is littered with
horror stories of people who started storing BLOB data in a db only to have
it slow down so much that it actually started moving backward. Similary,
other database maintenance became a complete nightmare and scaling the
systme upward become more difficult. Some of this is no doubt due to poor
implementations - but I think all in all, there's somethign to this. Now,
if your blobs are small and there sin't a lot of other data in the db etc
etc all of this is mitigated to a large degree. But even if it's the case
now, unless you are sure that it won't change, you run a risk of getting
bittne by it. I've went down the blob road and liked many things about it
but found the overall cost a little more expensive then the value it
produced. Eventually opted for storing file paths in the db and not had too
many regrets about it.

HTH,

Bill 

-- 
W.G. Ryan MVP Windows - Embedded
Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Let Microsoft know!
https://www.windowsembeddedeval.com/community/newsgroups
"Ken Beard" <KenBeard@discussions.microsoft.com> wrote in message
news:0DD80293-B570-4E82-BCEC-1CFFC960AFD5@microsoft.com...
> I'm looking for some ideas, I have a project to complete that has a
> requirement to store just about ANY type of document.  Most common
documents
> include Word, Excel, HTML, images, pdf, media files, etc.  I was thinking
of
> storing these into SQL Server 2000 as image type but my delimma lays with
> retrieval.  I was thinking of using a Microsoft Web Browser control to
> display the item to the user.  This works ok for 2 reasons, 1. The browser
> will open the appropiatte application to display the file and 2. I can
just
> use the Navigate(2) method to display the item.  The problem with this I
> don't want the requirement of storing the item to a file (filestream)
before
> displaying (Navigate needs somewhere to go).  I was thinking of
memoryStream
> but I see no good examples (other than image files) on how to do this,
> espcially on how to handle large files.  Is this a good approach?  Or
should
> I just stick with files stored on the server?
>
> THANKS
> -- 
> Ken Beard
> MCSD, MCP
Quantcast