1C:Enterprise supports the creation of one or more tabular sections for a catalog. You can use this option to represent data that is related to this item but does not have object nature (if the data has object nature, creating a subordinate catalog is recommended). For instance, you can create the UnitsOfMeasure tabular section for the Goods catalog.
Note that if a tabular section is used, you will not be able to reference the rows of a tabular section, in other words, you will not be able to create an attribute that matches the "tabular section row" entity. For instance, if you create the Education tabular section (instead of a subordinate catalog) for the Employees catalog, you will not be able to select a type like "graduated from" for document attributes. This should be taken into account when you choose between a subordinate catalog and a tabular section.
If you might need to reference subordinate objects in the future (for instance, to create attributes of documents or other catalogs that reference them), it is better to create a subordinate catalog from the very beginning. If a reference to such data makes no sense and can never be a type of a certain attribute, you can create a tabular section.
Below is a list of cases and factors to be taken into account to choose between a subordinate catalog and a tabular section. Study these cases in detail to avoid mistakes when making your choice.
You need to store a list of settlement accounts of each contractor in the database. You will most probably have to specify not only the contractor name but also their settlement account in all payment documents. This data is definitely of an object nature and can be identified as a "settlement account".
Solution: a Contractors catalog and a subordinate catalog SettlementAccounts with fields Bank, Number, and Account.
You need to store a list of units of measure for each product in the Goods catalog and to specify a conversion factor for recalculating each unit into the basic unit of measure. This data is collected from the UnitsOfMeasure catalog that stores all available units of measure. Each row of that subordinate list has no object nature of its own, it is only needed to recalculate from a certain unit of measure into the basic one.
Solution: a Goods catalog and a UnitsOfMeasure tabular section with fields UnitOfMeasure and ConversionFactor.
The default user rights feature is not enough for working with specific applications. A system that would allow different users to approve documents is often needed. In this case, you need to store a list of documents that a certain user (employee) can approve, and that is what the DocumentsForApproval tabular section of the Employees catalog can be used for. This data is not object-based, it simply connects a document and an employee, so you will probably never have to create references to it.
Solution: an Employees catalog and a DocumentsForApproval tabular section with the Document field and Is approved check box. Note that this task can also be solved with the help of information registers.
You need to store employee family data in the Employees catalog, which includes family members and their relationships with the employee (husband, wife, son, daughter, and so on). As a rule, this data can be represented as a list fully subordinate to the Employees catalog item, and one may consider creating a tabular section. However, if we think about it again, this data definitely has object nature and can be identified as a "family member". In some applications you may need to create references to the employee family members. A similar situation is observed with employee education and previous job experience.
Solution: the choice between a subordinate catalog and a tabular section depends on the purpose of your configuration. If you need to create references to certain data in the future, you may want to create the following subordinate catalogs: FamilyMembers, Education, and JobExperience.
Important! Remember that when you call a catalog item, it is read from a database into memory in full, together with all the tabular sections. If a tabular section contains a large number of rows, this may hamper system performance.
Therefore, a tabular section should be used if you do not have to store references to items and the number of items is limited.
Next page: Using chart of characteristic types to implement storage of values related to Infobase objects