1

I'm on charge of building an ASP.NET MVC Document Management System. It have to be able to do basic document management tasks like adding, editing and searching entries and also perform versioning.

Anyways, I'm targeting PDF, Office and many image formats as the file attached to each document entry in the database. My question is: What design guidelines do pros follow when building the storage mechanism? Do they store the document files in the file system? Database? How file uploading is handled?

I used to upload the files to a temporal location while the user was editing the data and move it to permanent storage when the user confirmed the entry creation. Is this good? Any suggestions on improvement?

David Basarab
  • 72,212
  • 42
  • 129
  • 156
Luis Aguilar
  • 4,331
  • 6
  • 36
  • 55
  • 1
    Use the FileStream capability of SQL Server 2008. – slugster Jan 16 '11 at 03:47
  • Part of your question - the question of storing files in the database has been asked countless times on this site. I've yet to see a sound reason for doing so, even if the DB has the capability. Jere's one of the earlier posts with food info. http://stackoverflow.com/questions/8952/storing-a-file-in-a-database-as-opposed-to-the-file-system – David Jan 16 '11 at 04:52
  • BTW, why build one when there are free ones available with huge user communities and better support? DotNetNuke handles it in the Professional version (even though it's not free) Confluence is another good one - java based, but not free, and they offer a heck of a lot more than just document management. I'm all for building things yourself, but this is one of those things where excellent tools already exists, and for the non-free ones, the cost is still a lot less than you'd invest building it properly. – David Jan 16 '11 at 04:56

1 Answers1

0

Files should generally be stored on a filesystem, rather than a database.

You will, however, have to consider some other things:

  • Are you planning on ever supporting load-balancing, replication, etc for your system?

    If so, you'll need to support saving / loading files from a network location of some sort.
    This can be trickier than you may imagine.

  • Are you planning to secure access to the files?

    If so, you'll need to ensure they can't be read by someone who happens to know the URL. eg: by returning the file as an attachment to a request.

    This also prevents user-provided files being executed on your server - eg someone uploading an .aspx or .exe file and then accessing it.

  • As far as I know, storing them on the file system involves high fragmentation of disks and low performance. Is that true? – Luis Aguilar Jan 16 '11 at 02:58
  • Significant disk fragmentation should only occur if you have a high volume of data churn (write-delete-write). Document databases tend to have content uploaded, and either deleted quickly (mistakenly uploaded) - or remain until data needs to be archived. Files don't gather fragmentation magically. If you provision your server to have plenty of disk capacity, and ensure maintenance is performed regularly - this should not be a problem. –  Jan 16 '11 at 03:08
  • It is disoputable, but after working on one such system: you are fired ;) Put them into the database, use SQL Server 2008 Filestream capabilities to get a disc space managed by the database so you have a single point of backup / restore, all the rest SUCKS from an adminsitrative point of view. – TomTom Sep 22 '11 at 06:01