Merging two IMatch databases / splitting up a db / the “right” folder structure

[Jim K.]

After getting acquainted with IMatch functionality and UI, I now would like to use IMatch in a productive way. So I try to find an appropriate folder structure for import in IMatch.

Actually there is a folder structure on hard disk for photos since 1998; all jpg with xmp, called Photos.

And then there is another folder structure with photos scanned in the past from the original analog photos; jpg, tiff and some bmp files, called Photos Historic. The link between Photos and Photos Historic is the people (e.g. grandfather in the 1950s and in the late 1990s).

Right now I tend to have two separate databases; but I would keep all the settings and fields for both db the same, e.g a field for the "source" of the scanned photos (like "photo page 4 is album labelled xyz in possession of my brother"), even it is not of relevance in the other database Photos).
 
First question: if my idea having two databases in the end turns out not to be good, is there some way to bring these databases later together in one single database (merging databases)?

Second question: is there a way to split up one database into two (so beginning with one common db and then finding out to keep the two areas separate would be better)?   

Third question: beside this more technical view, does the approach with two different databases for Photos and Photos Historic as described above make sense anyway?

[Mario]

I generally advice against having two databases. 
A second database for testing is OK. But not for productive use.

This complicates things unnecessarily and requires extra effort for manually keeping things like categories, metadata templates, favorites and settings in sync. This never ends well unless you a very disciplined.
It's just not worth it.

You can easily "split" your collection by using categories etc.

You cannot merge databases.
You can split databases by making a copy, giving it a new unique id and then use the "remove folder from database" to remove the folders you don't want to manage anymore. A lot of effort for very little gain.

Unless your collection is massive (I mean more than one million assets), I would not bother to use more than one database.

[jch2103]

You can easily "split" your collection by using categories etc.

Using Categories makes this kind of thing easy. And you can easily change/add/modify/etc. categories as needed. 

[Jim K.]

You can easily "split" your collection by using categories etc.

This is exactly the one sentence in the reply I really have to think about. Have to realize how to use categories in this context. Will play around with a test database. Maybe, if I could not come to a solution, I will reactivate this post later   

[Mario]

It's always preferable to partition/group/cluster within the same database using categories or whatever organization feature in IMatch you prefer.

Different from other "DAM" software, IMatch can actually handle large volumes of files per database without too much performance degradation. Having all your files in one database makes everything much simpler. From searching to backup.