This is a good idea, one of the prime places for a change. I can vouch that
it did impact the db performance to remove file storage from within the db.
I have a suggestion for those who need to store photos / big files and
cannot do away with it. One of our clients store scanned copies of all
documents submitted by their customers. The originals are submitted to the
bank. Specifically there are three kinds of documents - passport size photo,
identity proof, address proof (some times same as id proof). As these many
docs exist for every client, and for every account, an attested duplicate id
proof is again required, the number of documents swells very fast. What has
worked for us tremendously well (and we use it in our own products as well)
is WEBDAV over Apache for storing files on the filesystem instead of inside
DB.
In short:
1. We have a table called EntityType, which has a list of all master
types of entities.
2. We have a table called DocumentType, which has master types of docs to
store.
3. Finally, there is a table called Document, which has EntityType,
EntityID, DocumentType, DocumentDisplayName, other standard columns, and
most importantly, a "URL" for the document - the url being an address, size
char 256.
4. The actual documents are stored on the file system with a custom
naming system in a docdirectory.
5. We install and run WebDAV plugin over Apache.
6. The plugin makes this docdirectory available over Apache URL via
tomcat (Tomcat keeps a permanent auth over Apache)
7. Done.
1. Whenever we wish to show the docs on page, example: on viewaccount
page, or viewpersonnel page, or view officepage, above the notes, a small
list of document names are shown which are retrieved from Document table.
2. The link shown on these URLs is direct link to Apache WebDAV.
3. When someone clicks on the link, photos are served directly from
Apache, so it does not affect Tomcat's performance at all.
4. As you can see, as photos are stored in the file system, it does
not impact the db performance at all either. One has to make sure regular
backups of that directory are taken along with the db.
It isn't easy to do this in a packaged or clean way in our bandwidth to
commit to mifos main source, but if some one else wants to, please go ahead;
I can share more of the paralyzing
knowledge<http://www.gocomics.com/calvinandhobbes/1993/09/21>,
not that there is much of that.
Regards
--- Pooja.
On Wed, Jun 2, 2010 at 8:29 AM, Kay Chau <kc...@grameenfoundation.org>wrote:
> Hi all
>
>
>
> We are planning to remove some of the functionality around client photos in
> Mifos in this upcoming release (Shamim D). This feature is not optimized
> for performance, and we would like to improve this area significantly in the
> future.
>
>
>
> We will still provide the ability to view existing photos already uploaded
> for clients, but we are removing the ability to upload new or edit existing
> client photos.
>
>
>
> If you are using this feature, please speak up now!
>
>
>
> Thanks
>
> Kay
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Mifos-users mailing list
> Mifos-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mifos-users
>
>
------------------------------------------------------------------------------
_______________________________________________
Mifos-users mailing list
Mifos-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-users
