· Number of objects in a form page
A page should deal with a maximum of 100 objects. When the number of objects to be displayed exceeds 100 objects, group relevant data and use multiple forms to capture/display data.
In cases where a tabbed menu form that exceeds the maximum limit for objects per page is used, design each tab as a separate form and use goto links to navigate to these forms instead of using a single form with show/hide privileges configured to display relevant tabs on selection.
· Number of items in a select box
A dropdown select-box must not have more than 100 items.
It is a common practice to create a look-up relationship between models to provide a select-box with a dropdown. When the number of items in the dropdown select-box is more than 100, provide the advanced search feature by enabling the advance search option available in the “Connect” reference cell wizard.
· Number of child model instances displayed in a parent form
Avoid using one-many forms when the number of child model instances is greater than 25. However, if the data from the child model has to be displayed, then an additional reference with the filter criteria to restrict the child records can be created in the child model and used to display the data. This is not recommended as it would involve creating an additional (unwanted) reference specifically for the user interface.
· Number of objects processed by a R-Call or Child Call in an action
Ensure that the number of objects processed by an R-Call or a Child Call in an action is not more than 100. Where appropriate, use limit or criteria to control the number of records processed by these commands.
The system does not place a constraint on the number of records that can be processed. However, there will be a performance degradation associated with processing greater than 100 objects. The performance degradation will essentially translate into slower response times in the user interfaces.
· Number of parent-child relationships
There are no constraints on the number of parent-child relationships that can be created, but it is important to understand the inherent behavior of a parent-child relationship and create these relationships judiciously, only where it is required.
These relationships must be created only to implement composition relationships, where the lifetime of the child is dependent on the lifetime of the parent i.e. every child of the parent is deleted when the parent is deleted.
OrangeScape provides a unique set of database functions such as DCOUNT, DCOUNTA, DCONCATENATE, DSUM, DMAX, DMIN, and DFIND to operate on the child model instances from the parent model. Similarly, it also provides a DGET function to fetch the parent model values from the child model. When these functions are used in the rules perspective (defined directly in the public cells), these will be executed always to keep the parent model values in sync with the child model. Any changes in the child model will automatically fire the rules in the parent model and vice-versa.
In summary, a parent-child relationship will automatically perform a sync to keep the data consistent in the parent and child models. This could become an overhead when a parent-child relationship is implemented unnecessarily where only a master look-up is required.
· Understanding SYNC in database functions
By default, SYNC is TRUE for a parent-child relationship and FALSE for a look-up relationship.
The data in any two models with a parent-child relationship will be kept consistent (in sync) automatically while the data in any two models with a look-up relationship will NOT be kept consistent (in sync). However, the latter can be kept consistent by explicitly specifying the sync parameter while writing the functions in the rules perspective.
The SYNC parameter can be set to TRUE while writing a database function in a rules perspective to keep the data consistent between any two connected models (look-up relationship) for upto 100 objects.
· Using DSEARCH and DFIND
Firstly, all the depreciated API’s (Older DSEARCH function) must be replaced with the updated version of the DSEARCH.
The older version of the DSEARCH returned the value requested in the function. In cases, where more than one field value was required, multiple DSEARCH had to be written in the rules perspective. In the current updated version of the DSEARCH, the SheetId of the instance matching the specified criteria is returned. By establishing a formula reference on the DSEARCH field, any value from that instance can be fetched. This removes the need for multiple DSEARCH that was required earlier.
Secondly, DSEARCH function can be leveraged (used instead of DFIND) for improved performance when the number of objects to be searched is greater than 1000.
The DFIND function can be used to search for an instance satisfying the required criteria in the child model while DSEARCH can be used to search for an instance satisfying the required criteria in ANY of the models, not restricted to child models alone.
When a DFIND is used to search the child model instances, it does a search on the child model instances of the particular parent model instance being processed. If a DSEARCH is used for the same purpose, it would search all the instances in the child model. Hence, DSEARCH can be substituted for DFIND. However, DFIND is likely to yield better performance than DSEARCH for a fewer number of objects (in the hundreds) to be searched.