How so? How would you change it? Are you aware that they have written code into app_voicemail.c that allows you to store the actual soundfiles for voicemail in the database itself? You want to talk about poor database design...sheesh..
So, providing a uniform access model that doesn't depend on file paths, capitalization, or numbering is a bad thing?
Read it, makes no difference, it's broken :)Whats broken?
The table structure, did you miss it?
Also, it doesn't say why the table structure is the way it is.It most certainly does. Seems you didn't read the REAME after all.
<snip kindergarden database structure lesson from readme.extconfig>
Seems pretty simple and easy to use. This way if new config options are ever added, all you have to do to support them is to add a new column. And if all you are storing in most columns is 1 byte, it can't take up that much space.
"are ever added" That's entertaining. Developers working on special tasks add fields that may not ever make it into CVS stable. I think I've read of two or more that are in CVS-HEAD right now.
Flexible table structure isn't "we'll just add a field". Especially when the likelihood of new pieces of data needing to be tracked is high.
I don't claim to know everything about database structure, but that is my job, and I don't believe a flat table is the way to go. Trust me, I just added six fields to a flat table that I wish now that I had never created. If I can't get the time to rewrite it, I am sure I'll need to add six more fields within the next few months.
-- Andrew Thompson http://aktzero.com/ _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
