List boxes and radio buttons provided by Wagby are not suitable for selecting large amounts of data.From the operability of the user interface, it can be said that the number displayed on the screen as an option is 100 or less.
If this list box (or radio button) is designed as a hidden item and designed to hold more than 100 data, internally a large amount of SQL will be issued to prepare choices.In model definitions that contain many such items, performance will be problematic as the data volume of the choices increases.
Model reference items with a large number of choices are not list boxes and radio buttons,Search screenPlease define as.In particular, if you originally set it as a hidden item, it will not affect the appearance.
Since "search screen" does not prepare option information beforehand, it can reduce the number of SQL issue.
Wagby provides two definition methods as a narrowing-down method for list boxes etc. in the registration/update screen.
In the [a] method, once all the option data is acquired from the database, it narrows down.Therefore, it is unsuitable when you have a large number of options.
Since the [b] method narrows down using the where clause of SQL, even if there are a lot of choices, performance problems are less likely to occur.
If the number of choices is large, we recommend using [b] method.
Explain model A as an example referring to model B.Here, model B is assumed to be a model for master use.
When repeating containers, checkbox items, etc. are defined in the referenced model (B), all these items of model B are read using SQL at the timing of referring to the model from model A.However, on the model A side, this SQL processing is unnecessary if you know not to use these items.
For example, if "Data change historyLet's assume that we hold "In many cases, however, models that refer to this do not use change history information.However, from the viewpoint of performance, it is not preferable from the viewpoint of performance because it always manipulates repeating containers (this is another table) which holds the change history of data at the timing of accessing the referenced model.
Prepare a submodel that holds only the minimum necessary items in the referenced model.
In the submodel, you define only the minimum items that are used for model reference such as primary key, nonreference item, display priority item, invalidation judgment item, narrowed down item.From this reference model, you can suppress unnecessary processing by using this submodel.
If the data of the view is updated irregularly here, concern is raised that Wagby's model cache mechanism displays past data.Therefore, you can invalidate the model cache, but since this will issue SQL every time you reference the model, it will cause performance degradation.
Please consider the following method.