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
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.
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).
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 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.
Guidelines and design choices
Here are some random guidelines to designing a good data structure.
- Define the main objects you want to process information for: “Customer”
- Define what information those object have as their own: “Name”, “Address”
- Define sub-data that the object would own directly, and that would never be transferred: “Contract”, “Order”
- Define data that will be reused across multiple links or contexts: “Product”, linked in “Order”
When you want to have a field letting you select a pre-defined value, you also have two main conceptual choices:
- 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.
- 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 more into the details :