Tabular sections versus Catalogs

Understanding basics of 1C:Enterprise platform. To start working with 1C:Enterprise platform visit Getting started page

#1
People who like this:0Yes/0No
Active user
Rating: 3
Joined: Aug 19, 2019
Company: Asfarma International Pharma Marketing

Hello,

Tabular sections can be added to Catalogs as much as we need. My understanding is that, it is the short way to achieve one-to-many relation between MetaDataObjects.

Please see attached picture. Can we say if both side achive same DB diagram at the end? I mean, design on left hand side use Tabular Section approach, however design on right hand side use catalog approach.



Regards
Savas

 
#2
People who like this:0Yes/0No
Active user
Rating: 2
Joined: Oct 4, 2018
Company:

Hello!

The main restriction is: Tabular section can contain maximum 99999 records.
But you can easy display tabular section data in Catalog item form without any proggamming, only by add table linked to tabular section.
For any data links you can use linked Catalogs (Free or Subordinated to owner), also Information registers.
This not notably affects infobase size or speed.
The way you choose to your solution depends from what you need on result ).

 
#3
People who like this:0Yes/0No
Active user
Rating: 3
Joined: Aug 19, 2019
Company: Asfarma International Pharma Marketing

Hello Sergey,

I didnt know that tabular section has restriction. Thanks for pointing out. However it seems that it is practical option when it comes to rapid development.

Regards
Savas

 
#4
People who like this:0Yes/0No
Just came
Rating: 1
Joined: Sep 3, 2019
Company: Energy

Hi, Savas!

I can explain to you some of the differences between associated tabular sections and separated catalogs.
Actually these are the physical tables in the database. For tabular sections 1C:platform performs a transparent link between these tables "one to many". If you use the separated catalog you need to create a link between the catalogs through some attributes.
But.
When should we use separated catalogs and when associated tabular sections?
Pls, answer the question: do you need to create permalink between parent catalog and each (!) related item?
If you answer "yes", you need to use separated catalogs and link to the parent catalog through the attributes (or owner). If you use tabular sections, rows in the section couldn't have the permalink to the parent catalog, because they could be mixed inside tabular section at any time (the number of row in the tabular section might be changed by the user or algorithm).

 
#5
People who like this:0Yes/0No
Active user
Rating: 3
Joined: Aug 19, 2019
Company: Asfarma International Pharma Marketing

Hi Mark,

Thank you for your clarifications. I would like to answer your question but I cannot get what you mean by "permalink"? Is it relation or any constraint between tables? I searched documentation for this term but no luck.

Please clarify and thanks again for your comments.

 
#6
People who like this:0Yes/0No
Active user
Rating: 2
Joined: Oct 4, 2018
Company:

https://en.wikipedia.org/wiki/Permalink

 
#7
People who like this:1Yes/0No
Just came
Rating: 1
Joined: Sep 3, 2019
Company: Energy

Savas Karaduman,
I had in mind the next relations: for example, you have the catalog which contains employee records. Each employee has several documents of education. You can perform the list of these documents as tabular section in the catalog "Employees" and as a separated catalog "Education of employees" with the attribute "Employee" inside.
In first case you won't have a permalink between the employee and the rows in the tabular section (the user can mix the rows in tabular section, and you can't use concrete link for each row of tabular section in other objects).
In second case you have the concrete link between each employee and each document of education: you can use this link (permalink) of the item in catalog "Education of employees" in other objects.

 
#8
People who like this:0Yes/0No
Active user
Rating: 3
Joined: Aug 19, 2019
Company: Asfarma International Pharma Marketing

Thank you Mike for further clarifications.

 
Subscribe