Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've used both Liferay and Alfresco trying to use them as the Document Management System for an intranet.

I noticed the following:

  • They use the file system and the database to store files
  • They use a GUID to name the file on the filesystem and that GUID is used as an Id in the database.
  • The GUID-named file is a binary file
  • The GUID-named binary file stores all versions for a given file
  • The path for the file in the DMS doesn't match the one in the file system
  • The URL makes reference to the GUID when a certain file is requested

What I want to know is why is this, and what would be the best way of doing it. Like how to would you create the binary file (zip?), and what parts would you keep in the binary file and what parts would you store in the database (meta-data, path?).

I'm assuming some of the benefits of doing it like this. As having the same URL for a file, regardless of its current document path. And having only one file even if the file has changed names over time.

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

Storing large binary blocks as files is typically more efficient then storing large BLOBs in a database. It depends.

GUIDs have the advantage you can create one at random and use it without depending on some identity provider. Using a seed based ID generated in a DBMS would require you to first go to the database before writing a file to disk, with a GUID the order doesn't matter.

Document revisions can perfectly fit an append model. It can keep adding revisions to the file without causing too much rewriting. It also allows for smart storage and just storing deltas going from revision to revision, similar to what a version control repository would do. Otherwise using compression can also make a significant difference compared to storing the revisions in their own file.

It may also do this to avoid creating too many files on disk, which in turn may have a negative impact on performance. Copying around directories or making backups of directories with a huge amount of small files can be problematic slow.

Perhaps you should not look at the files as "files", it's just data. The GUID allows retrieval. Sticking it in the filename allows the file system to help out grabbing it.

You could do without a database, you may import some work though that a DB already does for you. In a hybrid approach I would typically put stuff in the DB that I would query on (e.g "Which documents are at path X?"). This would avoid having to create my own indices and such around the file based repository.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.