Optimal Size of Database

[jldodge]

Apologies if this is discussed somewhere but I could not find it.

I have a large number of photographs including my parents photos of the family. I am not currently a "professional" so most of my pictures are family oriented. We do travel a bit so I have many pictures, of late, that are the result of my desire to ultimately market on a website. I doubt that I will ever establish a full fledged photography business, i.e. wedding, portraiture, etc.

In setting up my DAM system, I am trying to determine the optimal size of a catalog or some parameters I can use to segment my picture collection. Some DAM systems have limits on the size of a single database but I could not find that information for iMatch.

Any help, advice, or counsel would be greatly appreciated. Thanks in advance ...

[Mario]

Welcome to IMatch.

Typical IMatch databases manage between 50,000 and 200,000 files. IMatch databases have no real limit, but, naturally, the more files you manage, the slower some operations will become. A good upper limit per database is about 500,000 files. Databases of this size still perform well on computers not older than two or three years.

An SSD is highly recommended for database storage because it speeds up everything.
Make sure to exclude the folder containing the IMatch database (and all files therein) from on-access virus checkers. They can ruin performance big time. See The IMatch Database for more information.

[jldodge]

Very helpful ... thanks.

Any suggestions from those who have segmented their pics into different databases? What was the scheme for the different databases? Any suggestions?

I would like to optimize the number of databases for searching and creating catalogs (which might incorporate pics that are incorporated into multiple databases. For example, if I were to create an album for one of our children that spanned a 40 year time span, I might have to incorporate multiple databases. NOTE: My files are stored in folders by year, then by date, and then by subject, e.g. Hawaii Vacation.

Again, thanks in advance.

[Mario]

This would make no sense. IMatch databases can manage a massive amount of files, which avoids the 'multiple catalog' disaster other DAMs may have to deal with.

Having multiple catalogs makes everything more complicated, without any benefit. From backup to searching to sorting to...
IMatch does not need (or support) searching files across multiple databases. It is rather unlikely that you will ever hit the 500,000 to 1 million files per database limit.

I don't know which software you have used before, but do you know that IMatch automatically organizes your files along a timeline?. Finding the files from a specific year or month or week or day costs only a single click. You can annotate time spans. e.-g. a vacation with a text or icon.

To identify and lookup files from specific events, persons, or combinations there of, you use keywords and/or categories.
IMatch makes it very easy to organize files into multiple albums (aka categories), manually, dynamically and automatically.

I can only recommend that you work with IMatch for a while, read the help section on categories and keywords and watch the free tutorial videos in the IMatch Learning Center before you decide on the best organization structure for your files.

[Jingo]

Very helpful ... thanks.

Any suggestions from those who have segmented their pics into different databases? What was the scheme for the different databases? Any suggestions?

I would like to optimize the number of databases for searching and creating catalogs (which might incorporate pics that are incorporated into multiple databases. For example, if I were to create an album for one of our children that spanned a 40 year time span, I might have to incorporate multiple databases. NOTE: My files are stored in folders by year, then by date, and then by subject, e.g. Hawaii Vacation.

Again, thanks in advance.

I too would HIGHLY discourage separating data by database... there will invariably come a time when you wish to include data between databases... and it become very confusing and in some case, impossible to do.

I use a single database to manage my personal photographs (my own and from other family members that share them).  With the ability to create multitudes of categories, keywords, labels and other metadata, it is easy to setup different criteria via filters and searches to narrow down and quickly find your data.  I concur with mario - give the demo a try with a subset of different data (photos, PDF files, music, you name it!) and try out some of the functionality... the program is very adaptable from the non-power to the power user.