| Containers, which need no version management |
| The data for these containers are stored in one or several tables, which
are filled once via SQL and then are not changed anymore. Examples: Geometry information as number of wires in MDC layers or RICH pad geometry |
| Lookup tables, ideal geometry |
| The data are stored in a couple of tables and the analysis reads only a subset
of the information. The filling is done via sql or separate programs and not possible via the analysis. But once filled, only a very data change and not very often. |
| Containers with a small amount of data stored in data elements, which might change in future code releases |
| For such parameter containers exists a complete environment including a WebDb GUI. By deriving them from HParCond and implementing two additional functions in the parameter container, one gets the Oracle read and write interface for free (and also the ROOT and ASCII interface) |
| Containers, with a large amount of data and often a tree-like strucure |
| By using a standard layout for these parameter containers in Oracle, it is possible to
develop a read and write interface with cut-and-paste and to use the new generic WebDb GUI. Typical examples: Calibration parameters |