Introduction to Data

Introduction to Data

Telerik Platform provides a NoSQL data storage that stores key-value pairs of JSON data called documents or items. Although these documents have no strictly-imposed schema, it is recommended to store documents that share similar structure in a dedicated collection, further referred to in the documentation as content type.

Schema Design

The lack of schema declaration and enforcement in the Telerik Platform data store means that the overall data structure's specifics for a given application must be handled at design time, according to the application's query and write patterns. There is no explicitly declared schema and no foreign key constraints. You need to take action to preserve the consistency and the integrity of the data.

The deliberate amount of allowed denormalization allows you to go with the strategy of storing (embedding) large amounts of related data in a single rich document. This alleviates you of the chore of creating many content types with relations between them. You can still create relations, although they only makes sense when imposed by the client app's data access patterns and their frequency or when you need to set up specific permissions for a given content type or content type items.

The data store supports atomic transactions on the level of a single document. When you embed data in a single document, you get the benefit of updating all the data in a single atomic operation.

Content Types

To save data in Telerik Platform you must first define one or more content types. A content type is a collection of data items that share the same data structure.

Creating a content type means defining the fields that it will contain. An identifier field is automatically created along with a few more system fields such as Created At, Modified At, and Owner. The identifier field stores automatically generated Globally Unique Identifiers (GUIDs).

A unique RESTful endpoint is automatically created for each content type. It provides immediate CRUD functionality over the stored data but you can also use the client SDKs to manipulate data in content types.

For better readability, the Telerik Platform portal presents content types in a tabular format, with a column for each defined field. Non-defined fields are shown in the details view.

Most of the time you will be creating content types through the Telerik Platform portal but you can also leverage the Administration API for the task.

Valid Data Types

Telerik Platform will accept and store any valid JSON document. Nevertheless, for the sake of future querying, sorting, and other operations on the stored data, you may want to insert coherently typed fields in each document.

The field types from which you can choose when creating a content type are listed in Supported Field Types. These field types are not automatically enforced but you are strongly encouraged to implement logic that does so. In all other cases, the database autodetects the supplied value's type and chooses a suitable internal type for it.

Internally, Telerik Platform stores data in one of the BSON types. Although you cannot choose a BSON type directly when writing data, you can query based on it. See Using Native Operators in Data Queries for more information.

Data Operations

Telerik Platform exposes full CRUD functionality over the stored data. You can use a large set of query and access instruments.

Operations on the stored data are atomic and consistent on a single-item level. There are no multiple-level transactions.

Follow the links in the See Also section at the bottom to learn more about data operations and querying.

Data Access Control

You can secure your types and individual items by defining content-type-level and item-level permissions and roles.

You can find further information in Introduction to Access Control.

Data Indexes

Telerik Platform creates an index on the ID (Id) field of each inserted document. The process is automatic and setting-less.

However, to take the most out of the data store, you are encouraged to organize your data according to the ways that you expect the data to be accessed. One example is saving related data in a single document. Also, query indexed fields whenever possible.

Unique Fields

In addition to the Id field, which enforces unique values by default, you can also set other content type fields as unique. After you do this, Telerik Platform will write new values to the field only if they don't duplicate existing values.

Preferably, you will set a field as unique when creating it. You can also set a field as unique later, but only if it does not contain duplicate values.

You can enforce uniqueness over multiple fields in a content type, but you cannot use a combination of fields as a unique index (compound key).

Some field types cannot be constrained as unique. These include Array, Relation (multiple), and system (CreatedAt, ModifiedAt, etc.) as well as the following Users fields: Username, Password, PasswordSalt, DisplayName, Role, Email, IsVerified, IdentityProvider, Identity, and VerificationCode.

Setting a field as unique means that you cannot have multiple null values in it.

You can have multiple data items where a unique field is not set. This does not stand in the way of enforcing the unique constraint for the field; if this makes sense for your application is up to you.

Data Relations

Telerik Platform allows you to define fields of type “Relation” in order to mimic one-to-one and one-to-many relations between content types. These fields store the Id of related items and are used when you need to retrieve the related data from another content type.

You can expand related data as detailed in the Data Relations section.

See Also

External links:

Start a free trial Request a demo
Contact us: +1-888-365-2779
Copyright © 2016-2017, Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.