There is no limit to the number of dimensions you can define in a cBase, but this does not mean that you should define all columns as dimensions. You need to consider the down stream effect. For example, when a ProDiver user opens a cBase, all diveable columns are offered as dimensions. This translates into overhead time and processing to determine counts for the console. The result can be a noticeable delay, as well as too many choices for the end user to work with—are all those dimensions needed in the console or are they obscuring the important dimensions?
When specifying the cBase, you have the option to flag columns so that they do not appear as dimensions by default. (Use suggested-dimension=false.) These optional dimensions can be promoted to diveable dimensions with DiveMaster or ProDiver. There is no performance difference for these dynamic dimensions, unlike with classic models—where only core dimensions are optimized, but the console does not count their values when first opening the cBase.
Using Suggested Dimension with Lookups
In a Build script, using a cBase as a Lookup, you might need to set the suggested-dimension=false for the columns retrieved by that lookup. You can mark a column as an optional dimension by replacing it with a copy of itself. For example:
build {
text-input "/common/basic.txt"
lookup {
text-input "color.txt"
key "Color" "Color"
column "Wavelength"
column "Hex"
}
replace "Hex" `value("Hex")` suggested-dimension=false
output "lookup.cbase"
}
NOTE: Use of lookups in Builds is preferable to using lookups in cPlans. Lookups are done at run-time, whether needed or not, and could be the cause of a delay for end-users querying data in a cPlan.
See also: