Making the case(s) for database-level scope of picture store location

[Fred Slota]

First, let's get the distractors out of the way...

 

Most typical cases, it doesn't make any difference where the setting is, at the program level or at the database level.

• The basic user with the default install never touches it.
• The user with multiple databases all pointing to the official store, as long as the setting is consistent/is copied across all databases, doesn't care.
• The common computer with multiple users, again as long as the setting is consistent/is copied across all databases, doesn't care.

For the user who relocates the storage location, it's slightly more convenient immediately after the relocation that the setting is at the program level and not the database level, as if at the database level, that user would have to adjust the stored location in each pre-existing database.  But, once that adjustment has been made, new and copies of databases would carry that new location over.

 

The main usage case is for those people who have multiple different picture stores.  For those who do, why do they have them?  Those who do have multiple picture stores because they find a reason to have more than one.  Meaning, they have times when they will be switching between them.  For this purpose, at this time, I want to interact with picture store 1.  For this other purpose, at this other time, I want to interact with picture store 2. 

Now, maybe these people have specific, discrete, separate databases that they associate with the different picture stores; For example, a personal databaase matched with personal scans vs. an online sales database with sales scans vs. a purchasing database with official scans.  These people definitely associate database -> picture store.  With sidekick, it doesn't matter how many different databases you maintain - it can automate weekly updates on multiple databases.  They load database 2, and switch to picture store 2.  They load back to database 1, and switch back to picture store 1.  and if they forget, things go wrong.

 

That leaves the people who maintain a single database and flip back and forth between the separate picture stores as they perform the different tasks that they feel require the different picture stores.  They could maintain separate databases, but since they have to switch stores anyways, why bother?

 

Well, for this I remind you of what currently happens when you change picture storage locations.   Picture references are cleared.  Whether flipping back and forth on a single database, or pointing custom database to custom picture storage location, picture references are cleared.  And, depending on what you're trying to do with the database with the different picture storage location, that probably means that you have to run Rebuild Pictures.  Every time.

If the setting was at the database level, after you set a database up with a new location and rebuilt pictures, you wouldn't have to rebuild pictures every time you changed between databases that used different picture stores.

 

Currently, it doesn't matter whether you use separate databases or a single database; you swap between picture stores, you probably need to rebuild picture references with each swap.

If the setting was moved to the database level scope, users with multiple picture stores would maintain separate databases for separate stores, and would never have to run Rebuild Pictures when swapping between different tasks/databases.  

 

And again, anyone who uses a single picture store would pretty much never notice and never care.