Typically, you base the decision to use Domains, Domain Topics, or saved reports on the complexity of the data and your business needs. Consider the following use cases:

In the first case, a Domain could contain dozens of tables in several unjoined sets, perform very little filtering but define a strong data-level security policy. Users of the Domain might see only a single set of tables according to their security permissions. They could then perform their own filtering, relabel columns for their own needs, and save their settings as a Domain Topic for reuse in Ad Hoc views. In this case, the organization may have only one domain but many Domain Topics that users have created for specific needs.

In the second case, Domains can be used to perform complex joins, have formulas for calculating new columns, filtering data, and selecting a small set of columns for specific users or specific types of reports. Perhaps reports also need to be internationalized, so the administrator creates the corresponding locale bundles. In this case, there might be many specific Domains, and each would have corresponding locale bundles and a single Domain Topic. Users would have a wide variety of Domain Topics to choose from, each for a specific purpose, but no opportunity to access the Domains to perform their own filtering.

The preceding examples illustrate two extreme cases, but many scenarios combine both to some degree . The number of users in your production environment and their level of proficiency also determine your general use cases. A small number of users who understand their database might be given administrator privileges to define complex Domains as an extension of the Ad Hoc view design process. On the other hand, with large numbers of users or with users who have limited database skills, administrators want to create Domains that help the users meet their business goals.

The table in Creating Topics from Domains describes individual use cases for Domains, Domain Topics, and reports based on Domains.