When to use references, queries, selections, and objects
1C:Enterprise 8 provides several methods to obtain data. References, queries, selections, and objects can be used to read data from object entities (i.e., catalogs, documents, etc.). For a detailed description of the differences between a reference, selection, and object, see section Using data types for manipulating database objects. This article contains recommendations on choosing the data access method.
As a rule, a query is the most efficient way of reading data. It explicitly specifies how to select records and what fields should be read. Therefore, when a query is executed, only the data that is required will be selected from a database and transferred to the client computer. If you use queries, you do not have to read fields and tabular sections that are not required in your specific case.
Another advantage of a query is the ability to read all the required data from several interconnected tables at once. Therefore, if you need to read data from several objects or obtain data from other tables connected with the objects, using queries would be more efficient than making several calls to different data. Note that from the performance point of view, the number of database calls is also important, not just the volume of data that is read, since every call adds to the overheads.
However, the query will read data from a database with each call. Therefore, if you call the same data multiple times, it will be read multiple times. You can avoid this by calling reference properties. In this case, object caching is used, and no repeat reading will be performed if object data is called repeatedly within a defined period of time. It should be noted, however, that when any field is called through a reference, the object is read in full (including all fields and all tabular sections). Therefore, a reference can be used for multiple calls if reading the full object cannot significantly slow down the execution. For instance, if you want to obtain the Posted property of a document through a reference, the document will be read in full (including its tabular section). If a tabular section of a document might contain several hundred rows, it is better to use a query.
Of course, if you need to call the same field within the same algorithm multiple times, it is better to read the data, store it in the memory as a variable and call the data already read. However, if you obtain data through a reference, the system may output the data that has already been read earlier, even if it was read in another call from 1C:Enterprise script, since data is cached for the whole client session.
The option of caching presentations is also worth mentioning. If, for example, you need to obtain a presentation of a catalog item, it is better to transform a reference into a string instead of calling the name through a reference. In this case, a special feature will be used to obtain presentations (as with the case with caching), and if the object's presentation is not yet cached, the object will not be read in full: instead, only the fields that are necessary to obtain the presentation will be read.
If you need to obtain a list of objects to display on the screen or send to print, it is better to use the Query object to create a presentation, instead of expecting the presentation to be created automatically when a reference is transformed into a string. For instance, if you output a sales report into a spreadsheet document, it is very easy to hamper performance tremendously if you output references to goods in your document. The report will be correct since the system automatically transforms references into strings. However, if you have several hundred or thousand strings, this can slow down the process of report creation tremendously. In this scenario, we recommended that you obtain presentations directly in the query and include obtained presentations in a spreadsheet document as strings.
A similar case is when you need to display query results in the form by dumping data to a value table or a value tree. If the cells of a table box display columns with references, this can slow down viewing of a value table in multiuser scenarios. This will also negatively impact individual user experience and the operation of the system on the whole. We recommend that you obtain both references and their presentations with the help of a query and have data displayed in a table box in such a way that cell text would be taken from the columns that contain primitive types only.
However, note the following: when a value table is viewed by the user, reference presentations are called as the rows are displayed; and when a query is used to obtain presentations, these will be obtained for all rows at once. At the same time, if you search through a value table, presentations for all rows will be selected (separately), which is a lot less productive than obtaining these presentations with a query.
When information is processed (e.g., when a document is posted), we recommend that you use queries to obtain object fields instead of calling a large number of objects via references. For instance, if you need to obtain a certain attribute for all products of the document's tabular section, it is better to run a query through the tabular section and obtain this attribute for each product, instead of iterating through this tabular section and obtaining an attribute for each product via a reference.
If you use a query, all data that is read is stored in the RAM of the client computer. If you need to process huge volumes of data, it is better to use selections. A selection does not provide the flexibility to filter and order information and it reads all fields and tabular sections of the objects. However, it does read data in portions and can therefore be used to process any volumes of data without storing them in the RAM.
When objects are obtained from a selection, they are not reread. This is why, if you need to perform mass modification of objects, using selections is more efficient than reading references with a query and obtaining objects for each reference.
As far as object search (searching for references to objects) with simple conditions (by code, name, etc.) is concerned, search implementation using queries and object manager methods (FindByCode() and others) do not differ much from the platform point of view. Use managers to perform single search operations. The main advantage of the managers is that they can be written in a module very briefly. Use queries if you need to search with complex conditions or to search for several objects.