1
The system of programs
The business applications
1C:Enterprise 8 Framework
New in 1C:Enterprise 8.2 Managed Application
New in 1C:Enterprise 8.2.14
Common framework mechanisms
Interface mechanisms in 1C:Enterprise 8.2 Managed Application
1C:Enterprise Database
Development with 1C:Enterprise 8.2
Scalability
Databases and Operation Modes
Client-server interaction model
Server cluster support
Geographically distributed databases
Thin client
Thick client
Web-client
Full-text data search
Administration tools
Localization support
Distribution and support of applied solutions
System Requirements
Used terms
Localization issues
On-line demo version
Geography of Solutions
Licensing policy
Partnership
Getting support
Partner area entry
About 1C

Operation with 1C:Enterprise Database

Principle of Operation with 1C:Enterprise 8 Database

1C:Enterprise 8 database includes a number of features that make it unlike other classic database management systems, such as those based on relational tables and which developers of universal systems deal with.

The main distinctive feature is that a 1C:Enterprise developer does not access the database directly. Instead, he works with 1C:Enterprise platform and can:

  • Describe data structures in the Designer tool
  • Operate data using the script language objects
  • Compose queries to data, using the query language

1C:Enterprise platform provides operations for data query execution, data structure descriptions and data operations, translating them into proper commands. These commands can be of a database management system (in case of client-server operation mode) or of the native database engine (for file operation mode).

Common System of Types

Another important feature in working with the database is that 1C:Enterprise provides a common system of types in the script language and for database fields. In other words, the developer defines database fields and the script variables in the same way, and operates with them similarly.

This gives 1C:Enterprise an advantage over other universal tools. Usually, when creating business applications with universal development environments, they use database management systems that are supplied (and developed) independently. This means that business application developers need to take care of the conversion between data types supported by one or other database system and the types supported by the programming language.

Storing links to objects

When handling data stored in 1C:Enterprise database the developer can use the object approach. In this way he can access (read and write) a certain data collection stored in the database as if the collection was a whole, single unit. For example, using the object approach one can manipulate data of catalogues, documents, charts of characteristic types, charts of accounts, etc.

A specific feature of object manipulation with data is that every object (as a data collection) has a unique link that allows you to explicitly identify the object in the database. This link is stored in a database field, along with other object data. Besides this, the link can be used as a value for a field of some other object. For example, a link to Contractors catalogue can be used as a value for a corresponding attribute of Delivery Note document.

Composite Data Types

A major benefit of the data model supported by 1C:Enterprise 8 is that there can be several data types defined for one database field at the same time. However, only one value is stored at a time, but it can be of different types — both reference and primitive types (such as Number, String, Date, etc.).

This allows simplification of the task. For example, an invoice may contain a Customer either as corporate person (from a Company’s catalogue) or as a private person (from Individual’s catalogue). When creating the database the developer can define a field to store a value of any of these types.

Storing Any Data as a Value Storage

The ideology of creation of applied solutions with 1C:Enterprise 8 presumes that all files relating to the applied solution are to be stored in the database itself.

A special data type was introduced for this — ValueStorage. Database fields can store values of this type, and the script language contains a special object with the same name, that allows conversion of values of other types into a special format of the value storage.

As a result, developers can store values whose types cannot be used as types of database fields. For example, graphic pictures.

Creation and Updating Data Structures Basing on Metadata

In the course of creation or modification of an applied solution the developer does not have to do anything to change the applied solution’s database fields’ structure.

It is enough for the developer to describe the structure of the used objects, the set of their attributes, tabular parts, forms, etc., by means of visual tools.

All actions to create or modify the database’s tables’ structure will be performed by the platform itself, on the basis of the set of objects and their characteristics.

For example, in order to make a Personnel catalogue capable of storing household information on employees, a developer does not have to create a new special table in the database, define rules to link data of the table with data in the main table, create algorithms of shared access to the table, check access rights and so on.

All the developer has to do is, with several mouse clicks, add a tabular part to the catalog and define two String attributes: Name and Relation. Upon saving or updating the configuration the platform will re-structure the database structures, create necessary tables, etc.

Object and Tabular Access to Database Data

1C:Enterprise 8 supports two ways to access data: object (for reading and writing) and tabular (for reading) ones.

When using the object model, the developer works with the script language objects. In the model an object (for example, a document) is handled as a single whole — it is loaded into memory entirely, including nested tables which can be accessed by means of the script language as a collections of records, etc.

When handling data, it ensures object integrity, caching, calling corresponding handlers, etc.

In the tabular model, an entire set (or ’collection’) of objects of one or another class is represented as an aggregate of interrelated tables, that can be accessed by means of queries — to a separate table, as well as to several related tables:

In this case the developer gets access to several objects’ data at a time. This is very convenient to analyse big volumes of data, for example when creating reports. However, due to the fact that data obtained in this way contains not all but only some attributes of objects being analysed, the tabular access does not allow modifying this data.


Useful links

   © 1C LLC

Your proposals on site send to:webmaster@1c.ru