CareerCup

I would use both,

DBMS for storing meta data like caller id, timestamp, date/time, call back number, voice message file id etc...

File system for storing voice message.

A single Voicemail message has the following (common) characteristics :::::: Sequential read always, Read in full always, Possibly replayed, but rarely, Small file sizes.

Assuming that a vmail system has to be developed for many users, we need a way to select all messages belonging to one user i.e. no sharing of vmail messages across users.

So, a simple system of one dir per user, with some small files under each directory, is sufficient. I.e. a file system would be sufficient. In addition, backup, replication, dedup and other tools built for a file system can be easily used for the vmail system as well.

I do not much about DBMSes, but it seems to me that we do not have any complex query system that needs to be supported for a vmail system and neither does any complex relationship info maintained. So a DBMS seems like overkill to me.

I would go with Filesystem. Storing and retrieving from DBMS is quiet slow compared to that of memory.

I think file system with inode structure saving all meta data.

I would suggest to use File System, because of the following reasons:

-> With File System the problem of storage can be tackled using the techniques of virtualization where as RDBMS will give rise to potential storage problem.

-> File System is portable can be scaled with minimum effort where as this is not the case with RDBMS.

-> If the system goes faulty, the downtime to recover and troubleshoot is less using the File System, where as with RDBMS, an entire day can get lost.

-> For RDBMS, we would need require an administrator.

I do in fact run a voicemail system, and the database is a very important part of it. Although it would be possible to partition the messages in different boxes using different directories, the database is needed to tag each message with not only whose box it's in, but who it's from, caller ID, urgent/normal status, private status, and any forwarded message it's tied to.

My system makes heavy use of messages that go from one box to another, including group distribution lists, so it would be impossible to do it with only a file directory identifying the box where the message is stored.

Sound files are stored as separate files, all of which are in one directory, and the database has the name of the sound file in each row identifying a boxholder's message. Sound files are saved with a numerical filename containing the date, time, and phone line it was recorded on to guarantee a unique filename for each message.