Database Documentation Platform update
Work with database in Tabbli


Databases are now a necessary component of any online-based software product and are an essential item of the digital transformation process of any modern business. The first generation of computer databases was introduced in the 1960s. Of course, a massive impact on the whole IT industry was made in the 1970s by E.F.Codd with inventing the relational database model. In his model, the database schema and logic were disconnected from physical storage. His ideas became standard principles for database systems for years and are implementing today in a lot of database systems, like PostgreSQL, MariaDB, MS SQL Server, SQLite, etc.

Photo by Joshua Sortino on Unsplash

Despite the broad spectrum of using, databases are still tricky for use by non-techy users. That is why many people are often using spreadsheet software (like Excel or Google Spreadsheets) even for problems when databases are just an obvious solution. The exciting fact is that SQL (Structured Query Language), which is now a standard de-facto language for query the data in relational databases, was designed in IBM in the 1970s as a simple language for non-programmers. But today, we can see that only experienced developers and data analytics are using SQL in their work. For many people, it is very complicated. Of course, the complexity of modern data operation tasks was increased dramatically. 

Nowadays, many people involved in the process of the creation of different software solutions, and many of them are not techy. Another issue is the specialized knowledge requirements of different database design patterns. Even modern "no-code" or "low-code" platforms, which provide visual interfaces for creating data structures and querying, require you some knowledge about database design patterns. Well, usually they say that you don't, but actually, you do. But if you need to store multilingual data or flexible structure, you possibly need to implement EAV (Entity-Attribute-Value) pattern, even if you are don't sure what it is. If you need to store tree-structured data, you also need to think about some design patterns. In many cases, it could be a real problem for the process of implementation of new ideas.

In Tabbli, the database is the main component of the platform. That is important because data is critical for each solution. We have designed a database component in such a way that you can think much less about implementation details. Need to store multilingual data? Just set a particular checkbox. Need to save different structures in the same collection? Just set another one. Need to keep nested records? Check another option. So, you do not need to implement different design patterns manually; you can use already predefined solutions.

Tabbli's database component introduces a few basic conceptions:

  • Property
  • Record type
  • Record
  • Collection

Let's dig into details.

Photo by Adeolu Eletu on Unsplash

Property. Tabbli supports a wide range of different property types for different types of values. You can save text, numbers, dates, geographical locations, relations with other data records, etc. All these properties use different widgets for forms and different rendering algorithms. Also, some properties can have a complex structure, like locations, or multilingual text properties. Any text property has optional support for multilingual data. You can also add any languages at any moment you need it without changing the data schema. Also, most of the available properties can set up like computed property. So, you can define a formula or template, and a particular value will be calculated automatically and stored in the database (when the record is modifying or by schedule).

A set of particular properties and some other options represent a Record type. So, generally speaking, a record type represents a data schema. You can create such many record types as you need.

When you create a data Record, you should specify a particular record type. It means that each record should have a strict schema. The schema allows building forms, interfaces, and filters.

Each record type is associated with a Collection. So the records of particular record types are also linked to a collection. In most cases, a collection contains only one single record type. It means that the schema is the same for all records of the collection. Still, there could be exceptions for some cases. For example, products (or services, or equipment, or something else) catalogs where you should collect different entities are pretty complicated in terms of implementation. Many software developers who actively work with relational databases use EAV design pattern for that, but it has a lot of disadvantages. Tabbli supports native support for working with different entities (record types) in the same collection. So, you do not have to think about implementation details but still can work.

In the next articles, we will describe other Tabbli's components like automation scenarios, public pages, etc. Check our solution gallery and request the interactive demo for details.