Data Structure

Data Types are the basis of your application. That’s where your data is stored, in a structured and defined way.

The data structure of your application is your first guarantee of quality information. A well-designed data structure forces the right information into the right places. This, in turn, lets you draw inference, that is, to understand the information better by observing links between pieces of information.

The Simitless data types structure

Person simple data tree example

Person simple data tree example

In a Simitless app data types are categorized into object types or field types. Objects data types are data types that contain other data types. Fields data types are just a definition of the value that the record will hold.

Simple Example

Each data record is an instance of the object type, containing the data corresponding to the field types.

For example, a person (object type) typically has a name (field type) and a date of birth (field type). Let’s look at “Bob” now. Bob is a person (Object record) and as such we create a data record with the name “Bob” (field value in object record) and a date of birth “1960-11-06” (field value in object record).

Nested objects data tree example

Nested objects data tree example

Nested objects

One of the special feature of Simitless compared to many database system is that Object data types can be nested. It effectively means you can place a table within the cell of a table (Excel metaphor). This feature also means that we have to introduce the concept of parent records and children records. A children record is a data record that is contained within a parent record.

Let’s look another example. If you consider an object “Customer”. A customer, similarly to a Person has a name, probably an address. Nesting object means you can create an object “Order” to represent an order that this customer would have placed in your system.

Nested data records are permanently under their parent record. A children record cannot be moved parent. Same as in life, you get the parent you were born with. In this system however, a children record has to have a parent, they cannot be orphaned. Nested records are deleted at the same time as their parents. When creating a children record directly, you will be asked to select or create a parent record before continuing.

Nested objects types are perfect for data that should not be re-used and not moved, such as work orders in the example above.

Linked objects

Linked objects are independent records that are linked to each others. These can either be from a main object type or even from a sub-object type.

Looking at our Customer and Order from the example above. We could imaging also maintaining a list of Products in the database. An order could then be designed to include a link to the product or even multiple products that are included in the order. The Product record being likely reused multiple times as Customers order the Products again, it makes sense to just have a link. We don’t want to have to re-input the details of the product in each order.

Display value and display color example:
3 rooms with display colors
and display value set to their name

Display value and display color example: 3 rooms with display colors and display value set to their name

Display Value and Color

The display value of the data is used when one value is needed to represent a data record. Using the icon in the data tree or on the data field type settings, you can enable a data type to be a representative type for the data object. The values of the data fields in the record will be assembled to generate a display value that will be used to show in places of the app where showing a full record is not practical. More than one value from more than one field can be used. The values are then assembled in the same order they were selected in the settings.

Display value and display color setting

Display value and display color setting

One special case is with fields containing colors. These can be selected to be a representative color in addition to a representative field for the display value.

Guidelines and design choices

Here are some random guidelines to designing a good data structure.

  1. Define the main objects you want to process information for: “Customer”
  2. Define what information those object have as their own: “Name”, “Address”
  3. Define sub-data that the object would own directly, and that would never be transferred: “Contract”, “Order”
  4. Define data that will be reused across multiple links or contexts: “Product”, linked in “Order”

Value selection

When you want to have a field letting you select a pre-defined value, you also have two main conceptual choices:

  1. A dropdown with a list of values that are pre-defined. This is mostly far cases where the values to be selected does not change often.
  2. A “lookup” table, this is a type of record that lives in your app and you can use a link field to go and select one record in this table. This is for when the values may change or application users are expected to be able to modify the values to be selected.

More Data Documentation

Look at the following pages to get more information on data types and dive into the details :