Datastore Forms allow administrators of the Kinetic platform to define and build up referential data that can be leveraged in other areas of the platform in a performant way. Examples of referential data include a list of Assets, Sites, Vendors, or Cities and States. Information stored in a Datastore Form can be configured to support many types of query combinations so that large datasets can be searched efficiently.
When working with large datasets, understanding how users need to query for data is very important to keep a system healthy and fast. Traditionally application owners would rely on a Database Administrator to design a database schema that was properly indexed for speedy searches. In the Kinetic platform, users can define their own fields (think of them as columns in a database). Datastore Forms allow system admins to define combinations of fields that users will need to query by. The application then builds index records behind the scenes to make sure that query will execute quickly on large datasets.
There are a few key differences between regular (Kapp) Forms and Datastore Forms. The primary difference is in the way one queries for Submissions (or records created) of one of these forms.
|** **||Forms||Datastore Forms|
|Optimized For||Transactional Data |
Forms are used for capturing data that has a defined beginning and end date (life cycle). Common use cases would be Orders, Requests, Incidents, Cases or Work Orders.
|Referential Data |
Datastore Forms typically store data that doesn't have a defined life cycle and has a well defined querying pattern. Common use cases would be Assets, Sites, Vendors, or Cities and States. (deterministic)
|Scoped To||Kapp |
Forms exist within Kapps (Kinetic Apps). A Kapp represents a collection of forms typically used to create an app. An example of Kapp would be a Service Catalog (collection of user requestable items) or a Case Management System.
Datastore Forms exist at the Space level of the Kinetic Platform. These forms are typically used to store data that needs to be shared between all Kapps. An example would be a list of Sites that both the Service Catalog Kapp and Case Management kapp leverage to build up Site Lists.
|Search across Forms||Yes |
Submissions within a Kapp can be searched regardless of form by using a predefined set of fields (Kapp Fields). An example of a query like this would be Submissions in a kapp where the Assigned Team is HR. This query didn't include a specific form, and is valid because Assigned Team is a Kapp Field.
Datastore Submissions have no shared (pre-defined) fields. You can only search for submissions in a single Datastore at a time.
|Ensures Uniqueness||No |
Forms don't allow form administrators to define uniqueness restrictions on submissions.
Datastore Forms allow administrators to set uniqueness restrictions on submissions. An example would be a datastore representing States. You would want to ensure that the State Name field would be unique, so that two submissions couldn't have the same State Name.
|Search & Sort Strategy||Ad-hoc Size Dependant |
Form Submissions can be searched using an ad-hoc pattern (ANDs/ORs) and the sort order is limited to a timeline (createdAt, submittedAt, UpdatedAt, closedAt). This style of searching is considered to be non-deterministic when using ANDs in the query (because an error is thrown if none of the individual comparisons match less than 1000 results for the specified timeframe) .
|Predefined - Admin Defined Patterns |
Datastore Form Submissions are queried using predefined patterns configured by the forms administrator. Large result sets can be returned in a paginated fashion and sorted in the order defined by the index. This style of searching is considered to be deterministic.
Updated about 1 year ago