@Riverman I don’t know what platform you are working on, Win 10 or Mac. I thought there was an issue with the Mac that the database location could not be specified but that is possible with the Win 10 and may have changed on the Mac (anybody?).
John-M made a comment with respect to the risk of the creation of Virtual Copies in any such “enterprise”.
The Win 10 Preferences option allows the database file to be specifically defined but that does not move the cache files which will remain in C:\Users<Username>\AppData\Local\DxO\DxO PhotoLab 5\Cache where ther are two subdirectories a Previews and \Thumbnails.
In two posts Synchronise PhotoLab - #26 by BHAYT and How to use PhotoLab on multiple Apple Computers - #58 by BHAYT I describe the issues that can create Virtual copies and also how it might be possible to avoid them.
Edits are stored in DOP files and these are essentially copies of data held in the database. If PL5 is being run on 2 systems there will typically be 2 databases one on system A and the other on system B and these will effectively point to the files on system A and on system B respectively. If any files are moved from B to A or vice versa (A to B) along with their respective DOPs then a Virtual copy will be created on the receiving system iff (if and only if) that system already has an entry in its database for that file in the given directory and the DOP does not have a unique identifier (Uuid) that matches the receiving database!
If this occurs then the receiving database preserves (protects) its existing data and it is marked as the [M]aster copy and the incoming DOP is used to create a Virtual Copy [1], in this way PL5 preserves both sets of data but there is now the issue of “cleaning up” the database to remove any unwanted Virtual Copies.
The best way to handle this is to avoid VCs if possible!
Essentially moving an SSD between systems where both the PL5 database and the files and their DOPs and any xmp sidecar files all reside should not cause any VCs to be created but to avoid many duplicate entries in the database the way each system refers to the database and the files should be the same, i.e. it is possible to have the same photo in the database many times over providing they are held in different directories and that will happen if System A has the SSD mapped as drive E:\ and System B as F:. In your case it would be useful not to have this situation but rather to have the same drive letter assigned to the SSD on both systems. e.g. they both “see” the SSD as F:\ for example.
Arguably you cannot relocate the cache file and theoretically it should not be a problem just moving the data (database, Photos, DOP, xmp sidecar) should allow rediscovery to take place or the elements of the cache will age and the new data will stored. Unfortunately I have seen a situation where PL5 showed an incoming directory with the same thumbnails as a previously deleted directory but this vanished on restart. If the drive letter is the same on both machines it may well simply re-use items from the cache, albeit there will have been updates of the other system etc. I have not done much work with the cache so I cannot give a definitive response to questions about it, i.e. about the cache.
There is a problem in choosing not to ‘sync’ metadata @platypus. Please note that PL5 will update xmp embedded data for JPGs (no xmp sidecar will be created) and create an xmp sidecar for RAWs) it will not update embedded metadata within the RAW files).
The ‘sync’ option effectively causes PL5 assigned metadata and externally assigned metadata to be merged. If that option is not set then metadata can be read into PL5 where it will overwrite any entries in the PL5 database or write the metadata where any metadata externally assigned (not in the list from PL5) will be lost. Please write in your response how you intend to manage your metadata, e.g. all in PL5, all externally or a mixture of both. There is currently no way to “merge” metadata except using the ‘Preferences’ ‘Sync’ option! I have been requesting such an option for months @sgospodarenko.
Now we come to the potential problems with PL5 itself. If you use ‘Ratings’ there has been a change between PL4 and PL5. In PL4 the ‘Ratings’ data was held and read from the DOP. In PL5 it is stored in the database and written back as xmp (sidecar or embedded as appropriate) to the photo (or xmp sidecar etc.). It is also written to the DOP but is not read back from there. Hence, you should treat the photo = photo + xmp sidecar at all times.
With the Tag there is a problem explained in one of my posts here PL5 Tag Field not read from .dop file - #93 by BHAYT. Basically the Tag is a piece of PL5 metadata but not xmp related, hence it does not belong in the xmp (embedded or sidecar) data. As such it is stored in the DOP and was read and written successfully in PL4 but in PL5 it is not being read back from PL5 DOPs (this is a bug).
I have included the above two items even though they should not really impact your data move because the data and the database are essentially staying together; all that should be happening is that a PL5 program on machine A or on machine B opens the database on the attached SSD and uses it as if it is the only machine responsible for that data and database. Please do not run PL5 without the SSD correctly attached because it will ty to make a new database!
It is possible that I have missed something please update the above @sgospodarenko