One or several databases?

[sinus]

I wonder, how many users does have several databases in IMatch.
The FR from Rene (https://www.photools.com/community/index.php/topic,12860.msg90787/topicseen.html#msg90787) brought me again on this question.

In the past I had 3 databases in IMatch. One for pics, one for video and one for other stuff, mostly office-files.

But if I changed in a DB something, then it was not in the other DB, so this was a bit akward for me.
And the computers got faster and faster.

Then I decided to put all in one (big) Database. But the main reason for this was searching.
Because if I had to search something, say "x-mas", then the search found not the "x-mas"-files in the office, if I searched in the image-DB and so on. 
And this was for me a great problem. (Loooong ago I used to have a software, what searched all DBs, but it is not more on the market).

Hence some years ago I decided to put all in one big DB. And this has really a lot of advantages. 
If I change something, it stays there, no other DBs. 
Searching: very cool, no forgotten files.
Quickly check a music, no problem, in the past I had first to load another DB. 
Backup: only 1 DB to backup.

And so on. The only point against having only 1 DB is speed, from my point of view. 
And, well, maybe, if you want work at home, then a big DB is ways bigger than a small one, if you want to work e.g. on some files only, and if you want copy the file.

But overall for me, I will stay with only 1 big DB, as long as it is quick enough ... and it is quick enough, even with my 358'000 files. I guess, even if I will have 450'000, IMatch will be still quick enough.
(Computers goes faster and faster, and Mario works to make IMatch faster and faster  )

Hence I wonder, if you have one or several databases with IMatch and if you would write some word about the reason, would be interesting, I think.

Have a good weekend!

[Rene Toepfer]

Great topic to discuss! I am also interessted in getting other user's opinion on that.

I run three databases:
1. Commercial jobs
2. Personal database, incl. family pictures etc.
3. Sternenkinder (Trigger Warning: Deceased newborns!)

These three are separated to make sure only me and my employees have access to commercial stuff. Personal is self-explaining why it is not included in 1 and 3. And 3 is just for me, separate folder where only I have access, no shared folder neither workstation nor NAS.

If I would have it in one Db the file size would become huge. In the beginning I had one Db containing 1 and 2 and it resulted in appx 20 GiB. Since separation I have two Db each appx 11 GiB, at the moment. If I add files to one of the Db only this Db must be copied for backup. Due to that I run 1 more often than 2, I save a lot of backup space. I have a backup using versioning of the files. This results in that I save currently 90 GiB compared to one huge IM Db.

The speed of IM was never and currently is not an issue or reason for splitting up.

[loweskid]

I used to have two databases, the main 'images' database and another one for keeping track of images I send to an agency.  After a while I came to my senses and merged them, mostly for the same reasons as you.

I still keep a seperate DB for music, which I very rarely use, and an old IMatch 3 database, mostly of old stuff spread about on dozens of CD/DVDs.  I've not needed to access it for years.  I can't be bothered to upgrade it - and anyway, I wouldn't be surprised if most of the CDs aren't readable any more!

And also a small 'test' database, for obvious reasons.

[Jingo]

1 database for me.. all JPG's (and a few movie files)... simple, effective and easy.

[Mario]

If I add files to one of the Db only this Db must be copied for backup. Due to that I run 1 more often than 2, I save a lot of backup space. I have a backup using versioning of the files. This results in that I save currently 90 GiB compared to one huge IM Db.

Does your backup solution always copy the entire file, not just the actually changed sectors?

If I use 20 GB IMatch database and make some changes to it, my backup software (Macrium Reflect) maybe adds 20 MB (!) to the daily backup, since it only copies the modified sectors of the file using the volume shadow copy service in Windows.
This makes backups very small, and keeping many versions of fat files very easy.

My total backup volume (full system backup) for my development workstation is currently about 8TB (8,000 GB).
An "initial" Macrium backup (weekly) takes ~4 TB (compressed and encrypted). The following daily incremental backups need only about 5-20 GB each. Differential backups are larger, but still much smaller than the original file size. It all runs automatically and in the background, while I can work normally. I can backup to external disks, the NAS or cloud storage. Which I all do.

[ubacher]

I have a seperate db for use on the laptop while travelling (several months of travel!)
Speed is the main reason!
For it I copy the main db, rename it and delete all files. Once home I move all files to the main db. That works quite OK.
I start out with a familiar setup but as I work on the laptop I do make changes to db settings which are then not reflected on the home db.
(Additional templates for printing, changed or added rename settings, additional favorites etc. There is no way
but manually transfering these one by one to the main db. (And remembering what has changed is the biggest problem.)
So I have the same wish as Rene to "synchronize db's".

PS: I do carry the main db and all files with me in case I need to access some files. For this I carry a 2TB Sandisk
USB (actually an SSD I think)

[Mario]

Design & Print templates are stored as files in the file system. Pack & Go transfers them for you automatically or you copy them manually.

[mopperle]

As I use IM not commercially, one DB is enough for me. It includes pictures and movies, no documents or other stuff. IM runs on a laptop with 3 SSDs (in total 4 TB). So enough diskspace for many pictures and I can take everything with me. Beside a daily systembackup, separate backups are written to 2 external storages (no SSD).

[thrinn]

I use two different DBs, one for everything related to photos, the other one for all kinds of documents. The reason to split them are the completely different folder, category and keyword structures. Reasons why I decided to use different databases were:

• Files are never shared between these database, so there is no risk of conflicting changes.
• I did not want to introduce some kind of top level category just to distinguish between "document" and "picture" categories.
• I also did not want to have both Keyword branches in the same Thesaurus.
• Some features (e.g. the "Recently used" lists which are available for different objects) work better for me this way because they only show "relevant" entries.
• Same goes for Favorites.

It works well for me this way. The most important factor is that there is no overlap regarding the files (and type of files) I manage in each database.

[stefanjan2]

I use two different DBs, one for everything related to photos, the other one for all kinds of documents.

Currently I just add photos and video to imatch. I did initially add everything but found it confusing. Imatch search for photos, drill down windows folders for everything else.

Separate databases sounds like a good idea if you could access them concurrently but I wonder how practical to close photo dB then open docs dB to find a document. Or am I missing something?

[Mario]

I can only speak for myself.

I often do projects which involve hundreds of RAW images, video footage, audio recordings, lots of documentation and auxiliary files of all sorts. RAW files usually serve only as input for things I do. I often combine dozens of RAW shots into a final Photoshop file. For vector graphics I use Affinity Designer 2 and for 3D stuff I use Blender.

For me, it makes sense to keep all files of a project together in standardized folder hierarchy.
And I do that in IMatch, obviously. This way I can see all project files, use buddy files and versions, rename related files in one go etc. I find that comfortable and it saves me lots of time.

I also maintain about a dozen IMatch databases I use for development and testing.
The smallest has only one folder (for super-fast startup 100 times a day) and the largest manages almost one million files. This is the database I use for performance tests and optimizations.

Occasionally, I export/import categories, thesauri or layouts using the tools provided by IMatch.

If I really have to re-create a complex Renamer preset, I make a screen shot of the original (so I see what comes in which order) and reproduce it in a minute or two. If I have used complex variables, I copy them into Windows Notepad and paste them into the new preset. I also keep many often used variables in IMatch Notepad, which allows me to reuse them quickly in any of my databases.

[thrinn]

Separate databases sounds like a good idea if you could access them concurrently but I wonder how practical to close photo dB then open docs dB to find a document. Or am I missing something?

It really depends on your needs. For example, if I had the kind of projects Mario describes in his post, I would also use one database. The important point is that, in his case, these files (documents, videos, photos) belong together or to a common project.
But I am only a hobby user of IMatch. When I am looking, say, for some insurance correspondence or an invoice, I know that I will find it in my "Documents" database. And this document will not have anything to do with my photos. Organizing my photos is (for me) a completely different task. I simply don't work with both databases at the same time. Therefore, the need to switch between databases is no issue for me.

My opinion is: If in doubt, use only one database (plus maybe a test database to try things out). I use my two databases for different things and with different "Workflows", that's why it works for me.

[RobiWan]

Both variants have their advantages and disadvantages. I use 2 databases myself, but in reality it is one. One database I use on the road to already keyword new images and provide them with GEO coordinates. Later, when I come home it is replaced by the original file (i.e. empty database with my keywords and other defaults).

The problem @sinus describes could be solved if IMatch could keep multiple instances open at the same time. So my 5 Cent

Robert

[sinus]

Separate databases sounds like a good idea if you could access them concurrently but I wonder how practical to close photo dB then open docs dB to find a document. Or am I missing something?

...When I am looking, say, for some insurance correspondence or an invoice, I know that I will find it in my "Documents" database. And this document will not have anything to do with my photos. Organizing my photos is (for me) a completely different task. I simply don't work with both databases at the same time.

I throw almost all documents into IMatch. Insurance, tax-doc, InDesign, Corel, pds, word, html, Blender, Excel, private docs, privat photos, videos, all stuff.
And it works simply very good, for years, hmm, for about 20! years now.
Best thing for me is searching. Nothing can go forgotten, if I search. IMatch will find it.

I have a good naming-convention. Find all private photos, or all invoices and so on, no problem. Find used raws and the copies, also no problem, also unused raws and so on (ending in the names).

Lately I found an old invoice, what I sended to my brother for CHF 4.95 - that is -I think- about 5 dollars or euros (roughly). He wanted have this invoice for his football-club. Was nice to find it again by coincidence.

But, like Thorsten wrote, it depends. As I wrote, once I had 3 DBs, nowadays only one. At the moment I will not go back. But if I would like to do so, IMatch would allow me to do so.
And that makes me relaxed.

[Mario]

It will never happen that IMatch opens more than one database at a time.
I fear even thinking about the massive amount of work this would cause. We're talking about many months of development time, and many months more to find all the bugs introduced. And this assumes that this is even feasible.

As this thread shows again, not many users use more than one database for productive work. It's just not worth spending months of work and tons of money on this. This will never pay back.

[Rene Toepfer]

If I add files to one of the Db only this Db must be copied for backup. Due to that I run 1 more often than 2, I save a lot of backup space. I have a backup using versioning of the files. This results in that I save currently 90 GiB compared to one huge IM Db.

Does your backup solution always copy the entire file, not just the actually changed sectors?

I can set to copy only changed blocks but I do not trust in this way to copy files. My main concern is, if there is something to the main backup file all differential copies are useless. To minimize the risk I would have to copy on each, e.g. tenth run, the main file again. Maybe I should re-think this way...
For my purpose I use Syncovery since more than a decade. It is not only available for Windows but also Linux therefore I can use it for my Synologys too.

[Rene Toepfer]

I often do projects which involve hundreds of RAW images, video footage, audio recordings, lots of documentation and auxiliary files of all sorts. RAW files usually serve only as input for things I do. I often combine dozens of RAW shots into a final Photoshop file. For vector graphics I use Affinity Designer 2 and for 3D stuff I use Blender.

For me, it makes sense to keep all files of a project together in standardized folder hierarchy.
And I do that in IMatch, obviously. This way I can see all project files, use buddy files and versions, rename related files in one go etc. I find that comfortable and it saves me lots of time.

I work the same way. My folder hierarchy is the same since many years. During the years I have developed a structure in naming files which includes a counting number of the variant followed by revision. This makes it very easy to look for files. Therefore, it was important to me that a DAM does not create its own structure and numbering.