Types of specs
Most typical solutions keep the number of specs around 100 count. The number may sometimes reach into the 100's as long as the size of the individual specs is small.
Going beyond 1000 requires extreme care and consideration as it dramatically increases the memory requirement on the system. Larger number of specs lead to larger more complex views that increase the memory footprint of individual users. This type of solution requires highly custom tuned load balancers as well as garbage collection settings.
In some cases, there are requirements to handle category-specific attributes, which might lead to thousands of specs. Ensure that you involve architects and engineers in the design discussion. Alternative designs should be considered first, and if no feasible alternative exists, then potential implication needs to be analyzed.
- Primary spec
- A primary spec is the data model that is used to define hierarchies and catalogs. A primary spec must have a primary key.
- Secondary spec
- A secondary spec is the data model that is used to define location attributes and supplementary attributes that are associated with particular categories. Secondary specs do not have a primary key.
- Sub spec
- A sub spec is a reusable spec, which can be used as part of either a primary or a secondary spec, for example, to group a set of attributes that always occur together.
- Destination spec
- A destination spec defines the structure of the data that is exported to a destination data file for a catalog or hierarchy export.
- File spec
- A file spec defines the structure of a data file from a data source to use for a catalog or hierarchy import.
- Lookup spec
- A lookup spec is the data model that is used to define a Lookup Table. A lookup spec must have a primary key.
- Script input spec
- A script input spec defines the structure of the parameters that are passed to a script API, especially a script that runs through the system user interface. For example, a report script.