If you've used Digital Asset Management software before, you've probably encountered features with names like Smart Collections, Dynamic Collections, or Categories. Although the names differ, the underlying idea is usually the same: define a set of rules and let the software automatically gather the images that match those rules. On the surface, that sounds straightforward enough. Under the hood, however, there are two fundamentally different ways to implement such a feature. The difference isn't merely technical. It reflects two very different architectural philosophies.

Storing Answers

Imagine creating a collection with the following criteria:

• Rating is 5 stars

• Appearance is Landscape

• ISO is greater than 200

One approach immediately executes that search, stores the resulting list of matching images, and continuously updates that list whenever metadata changes.

From the user's perspective, the collection appears dynamic because its contents change automatically. Internally, however, the application is maintaining a stored result set. Database systems refer to this concept as a materialized view: the result is stored and must be kept synchronized whenever the underlying data changes.

This approach certainly works, but it comes with responsibilities. Every metadata change raises questions.

• Does this image now belong to another collection?

• Should it be removed from an existing one?

• Which collections need to be updated?
  

The application must continually maintain those membership lists to ensure they remain synchronized with the catalog. If synchronization fails, the stored result no longer reflects reality. Some applications therefore provide commands to rebuild or recalculate their dynamic collections after significant metadata changes.

Storing Questions

There is another way. Instead of remembering which images belong to a collection, the application remembers only how to find them. Whenever the collection is opened, the search is executed against the current catalog. Database systems know this concept as a view. A view stores the query, not the result.

This seemingly small distinction has important consequences. There is only one source of truth: the catalog itself. No collection membership needs to be maintained because no membership is stored. Nothing can become out of sync because there is nothing to synchronize.

Every answer is derived directly from the current state of the catalog. This is the philosophy behind Dynamic Collections in Photo Supreme.

A Dynamic Collection Doesn't Contain Images

Once you understand this design, Dynamic Collections become remarkably simple. A Dynamic Collection doesn't own a list of images: It owns a question.

Whenever you open the collection, Photo Supreme simply asks:

The answer is calculated using the current state of the catalog. If you change a rating, assign a label, or modify any other metadata, the Dynamic Collection itself never changes: only the catalog changes. The next time you open the collection, the answer naturally reflects those changes.

There is no separate list to maintain because no separate list exists.

Describing a Search

This immediately raises another question. What exactly does it mean to "store a question"? The answer is not a SQL statement, nor is it tied to any particular database technology. Instead, Photo Supreme represents a search as a structured definition describing what should be found. That definition captures concepts such as conditions, comparison operators, logical relationships, and grouping.

In other words, it describes the user's intent rather than the mechanics of executing the search.

This distinction is important because it separates what the user is looking for from how the application chooses to find it.

A Shared Language

Once a search has been expressed in this neutral form, it becomes much more than a single search. It becomes a reusable description that different parts of Photo Supreme can understand. Dynamic Collections are one example. The Catalog Filter uses the same concept to limit the images currently displayed. Dynamic Searches use it to execute ad-hoc searches. In the Server Edition, user visibility restrictions are expressed in exactly the same way.

Although these features solve different problems, they all share the same language for describing what should be found. That consistency is one of the strengths of the architecture.

Separation of Responsibilities

Describing a search is not the same as executing one. One part of the application is responsible for expressing what the user wants to find. Another part is responsible for finding it as efficiently as possible. The catalog itself simply stores the information.

By separating these responsibilities, each component can focus on doing one job well. It also allows the search engine to evolve independently of the user interface or the underlying database technology.

Dynamic Collections Are a Consequence

It is tempting to think of Dynamic Collections as a dedicated feature with their own implementation.

Architecturally, the opposite is true. Once an application has a robust way of describing searches independently of both the user interface and the database, and once it has an efficient search engine capable of executing those descriptions, Dynamic Collections become a natural consequence.

A Dynamic Collection is simply a saved search definition. Whenever you open it, that definition is evaluated against the current catalog. There are no membership lists to synchronize. Nothing to rebuild. Nothing that can drift out of sync.

Just a stored question that always produces a current answer.

More Than Dynamic Collections

Although this article has focused on Dynamic Collections, the underlying idea reaches much further.

The same mechanism is used wherever Photo Supreme needs to describe what should be found rather than how to find it. That is no coincidence.

Rather than solving the same problem repeatedly for different features, Photo Supreme defines the concept of a search once and allows multiple features to build upon it. Dynamic Collections are therefore not a special subsystem. They are simply one visible example of a broader architectural principle.

Sometimes the most elegant features are the ones that emerge naturally from its foundation. Dynamic Collections are one of those features.