Infostore persisted to MySQL instead of FS?

[mendosoft]

From what I know of OX (I'm still ramping up on details...), the actual document for an Inforstore item is stored in the underlying FS (in the 'filespool' config dir and structured subdirs). The metadata IS in MySQL in the infostore* tables - no problem there.

I have a corporate client who might want the actual document to be persisted to MySQL (or a JDBC datastore) instead of the FS. This is for policy and 'auto replication' reasons, though I'm sure these issues could be adequately addressed by replicating the FS datastore currently underneath the Inforstore.

So is/are there plans and/or reasons not to persist Infstore to MySQL?

TIA.

[Martin Heiland]

Well, just imagine how slow your DBMS will get if you start to store billions of bytes to BLOBs in the database instead on the file system. Databases are made for managing defined amount of data per database field. Small fields improve database performance a lot. Extremely large database fields would kill every database I/O. I am sure there is a way to save the `real` Infostore files to the database, but i can really not imagine why somebody should do something. Replicating several gigabytes of databases just for backing up plain data files will be very funny to... i suppose it is good the way it is done right now.
AFAIK there are some partners already on it to provide full backup solutions for Hyperion - this would solve the problem your client maybe has (fear about inconsitent backup)

[mendosoft]

Totally agree - thanks for clarification...

Point taken re: proper use of a DB vs FS.

I'm in a very policy-driven and controlled internal corporate environment where they like to standardize things like backup. Right now, their database backups are independent of the FS backups, so there's an issue of synchronization upon restore at any given time T.

Most of this is mitigated by building a redundant backend architecture, something that OX and MySQL can do just fine, so the probability that you'd revert to a 'backup to tape' rather than just switching over to a redundant 'always on' backup system is quite low. Given this, the backup sync between DB and FS isn't a huge issue, IMO.

Again, this is corporate (US) client I'm representing and it's in the banking/financial services sector where controls are very tight and standards (i.e. Microsoft) can drive technical decisions more than choosing 'the best software'. So you can end up with somewhat illogical technical setups/ideas in order to support an irrational IT decision making process - in this case a 'standardized' backup model that doesn't handle syncing data that resides in a DB vs a FS.

Enough of all that - thx again for the clarification.

[Daniel Halbe]

Every database driven applications will run into problems if you run different versions of (frontend-)files and database.

Every database driven MS product will run into the same problems because it is absolutely unrealistic to restore only database or (frontend-)files of an application.

I really can nor belive a financial institude acts the way you described:
- I see no logical reason for this
- No software can run without problems when (frontend-)files and database are not same re3lease / version / state / restore.
- This would make every process more complex

I'm familar with internal software portfolio of some of the biggest european financial institutes like Deutsche Bank and can say I've neaver heard of such requirements.

If you want discuss this topic in private feel free to write me a private message.

Daniel Halbe