Thanks for the warm welcome Oxidant. There’s some very smart people using DxO Photo Lab and related tools and participating on these forums. You asked:
One thing i can’t oversee but i think it can be a issue is when having a DAM guarding your rawfiles and a DAM guarding your endproduct (jpeg) could this bring a conflict in database?
That’s the whole point. I’d suggest only tagging, naming and indexing finished product. Raw (RAW) images would just be in named folders by date. Those RAW folders would only contain the selects (everything else would be thrown away) for potential reprocessing.
Finished images would be carefully catalogued, named, key-worded, labeled, face ID’d, IPTC filled in. Whatever the individual photographer feels is necessary or helpful for the long term use, preservation and sale of his archive.
Saves a ton of busywork on incoming thousands of images and makes it realistic to achieve a well-organised archive of finished images.
Where that archive is kept - Aperture, standalone Lightroom 4 or 5, iMatch, PSE, Bridge - doesn’t matter. What’s important is that the finished catalogue suits the photographer’s needs and that the images can be stored in folder structure at OS level in case something happens to catalogue tool. With good backups, if the tool allows perfect nested folder output of original ingested images, one could allow the catalogue to store the originals in its own hidden internal structure.
Curiously the software which doesn’t let you use OS level folders are the same ones with broken export (not just in image management). Otherwise known as vendor lock-in. Once you put your images or data in here - you’re never seeing them/it again in one piece if you leave.
Original RAWs in this simplified system
The original RAW changes would be stored in sidecars with the RAW file. You’d find it again for reprocessing by date and by potentially including the original file name within IPTC. The original RAW files would not live in the catalogue.
Relational Management, Versioning, Intermediate File: Obetz
The link you sent is really useful Obetz. My head spins and my stomach churned reading through all of those contortions to try to keep keyword data in some kind of sync. Relational data like that is extremely fragile and is certain to fail or go out of sync (probably silently at some point in the future). iMatch is very brave to even attempt image management of this sophistication.
Everyone inside DxO who thinks it’s a good idea to build a DAM should be forced to read that link [Configuring File Relations](See IMatch Help System) five times and pass an exam on the contents. Complex headaches like this are why DxO should stay as far away as possible from the DAM side, instead building out partnerships with the best in category and/or simply popular triage and DAM tools. There’s at least five years of hard work with good programmers to get to the starting line of where iMatch is now.