Open Source Document Management System | OpenKM

While configuring OpenKM 5.0.3 I am wondering whether it is better to stay with the default database or to use another such as MySQL.

Is there any document defining the pro's and con's of using the different databases?

Sean

Yes there're some diferences. But if your system has less than 100GB then you can stay in default OpenKM configuration. If not then we can consider talking about it.

Other related question could be how want to doing backups etc... now you must copy entire folder, etc... you could store all on DBMS, we don't suggest it because there's some delay getting blobs from DBMS than on disk are fastly readed ... etc.... TEll us the use and then we can orientate on it.

Hi,

Thanks for the response. We are obviously far away from 100GB and I do agree concerning the blobs.

Our system will be storing customer documentation such as debit order forms, copy of ID and municipal utility bills so there will be a steady stream of documents added to the repository in PDF format.

The documents will be received fax to email and so be in PDF format when they arrive in the mail inbox which OpenKM will monitor. Once they are imported the next interaction is user input and control via workflow.

OpenKM will not really be used for much more than this. It is just the repository for electronic storage of the documents mentioned adding about 400 - 500 PDF documents per month.

Our ERP and CRM systems will be integrated to OpenKM such that when looking at a customer record in CRM or ERP the web service will display the information related to the client inline with the ERP or CRM interface.

The question would be ... how easy is it to migrate the database when the limits are reached? I consider that the slowness of retrieving blobs from a database may be a small price to pay for not having to migrate to another database later. In reality within the use case the documents, once stored, will not be accessed on a regular basis. Only in particular instances when we need to check something because of a customer query and then we will only be accessing that customers documents.

For the most part the display of information from the CRM and ERP side is just displaying meta information.

Hope this helps.

The server it'll be your intranet no ?

400-500 documents per months is not much, at the year we're talking about 5000 documents (normally can considering a document it's 1MB ), we're talking about 5GB per year. Any configuration it'll be right for it. In this case I could suggest MySQL, basically because it's more operational than embedded to make queries.

Other question, how do you plan make backups, that's really important. Daily ? and where ? external USB could be valid to you, or other system.

After it I could suggest more approximate environment. The problem on DBMS is that could not be done incremental backups, that other reason why have mix installation, some information on DBMS and other in hard disk ( the blobs ).

In general storing the document in the filesystem is the best approach. This is a configuration parameter in repository.xml called FileDataStore. But if you want database hot-backup or on-line replication you should store all the documents also in a transactional database like PostgreSQL or MySQL with the InnoDB engine.