Diffidently asked: will there ever be a chance that IMatch uses regular SQL-DB?

[real_skydiver]

The title says it already. I'm curious about this because I'm so much in use to those DB's (Oracle, DB2, MySQL) as a Developer - I would love to see this happen one day. Plus, I think - or is it more a feeling - that in a multi-user scenario a SQL-DB (client-server) would make things easier.

[Mario]

I've worked with ISAM, relational, OO and multi-dimensional database systems in corporate environments over the past 20 years.

IMatch uses a reliable and robust embedded SQL-Database at the lowest storage level. This system is also used by companies like Adobe, Google or Apple.
On top of that sits a hybrid object-relational/multi-dimensional database system of my own making.

It is possible to exchange the bottom layer and switch to, say, MySQL or SQL-Server. But what would be the benefit?

A much more complicated installation and upgrade procedures. Normal users dealing with MySQL-related problems? Don't think so. And there are of course licensing issues (shipping MySQL with an application creates about 10 pounds of legal headaches). And as far as I know, using the MySQL APIs in a commercial product has also many strings attached....

Switching to a multi-user database system like MySQL or SQL-Server will solve none of the multi-user related problems in a system as complex as IMatch 5. For example, user A imports 200 new RAW files into IMatch on his PC. This requires updates to all data-driven categories, generates a ton of new @Keyword categories, requires changes in all collections, runs Metadata Templates, writes-back data etc. The key problem here is how to synchronize all these changes to the 10 other users using IMatch in writable mode at this time? How to prevent concurrent changes by multiple users to the same data? How to push changes made by one user to all other users. And similar issues.

It would be doable but incredibly complex to implement a system like IMatch 5 as a true multi-user system. It would not only require a true multi-user database system, but also an true "IMatch Server" component which controls everything. A server which implements check-in / check-out features for categories, which is able to push changes to workstations, lock sections of the database to prevent concurrent changes to the same data by multiple users and so on. Swapping the bottom storage layer to another database system is only 5% of the effort involved. I would not even attempt such a thing without a large developer team plus support staff.

Companies like Canto, Extensis and FotoWare have such systems already. They are all in the multi-thousand dollar range, usually require on-site consulting to setup and implement and annual service contracts. Dedicated hardware etc. All for good reasons.

[real_skydiver]

Very well answered, thanks for that. To be honest, I expected exactly this sort of answer, all of what you stated is undoubtedly true. Changing that bottom layer would still leave a lot of issues open. And you're probably - certainly right, not everyone is willing to deal with any type of database installation - and maintenance of course.

Still, since I wrote a couple of client-server systems (CORBA-based, mainly Banking-related), I would love to see IMatch some day to become a true multi-user system ... said that, if I would be in your position (writing Desktop-Software, mainly for single-users)  I would probability neither waste a single thought about it.

Thanks again for your answer.

[real_skydiver]

Oh, btw., just bought a copy of IMatch, even without the client-server functionality

Thanks again for your time.