An Easy Way to Improve Your ENOVIA Performance

Why Do Inefficient ENOVIA Data Retrievals Occur?

The most common mistake in the implementation is the way in which data is retrieved from the database, and especially an excessive usage of database calls. Even if a single database call could be very simple – taking one or a few milliseconds to complete – multiplying will instantly develop the time spent into seconds.

A call to the database, first, has a static overhead of its own that each call has to take. And second, it is usually easier and less consuming in total for the database to do the same query on multiple objects at once instead of having to redo the same query over and over again for each single object.

Inefficient ENOVIA Data Retrieval

The example below tries to illustrate what the difference could be by implementing in different ways, even though the visual end result for the user is the same.

In this example, a table containing Y number of columns and X number of rows is used, but the same idea of data retrieval is applicable for a lot of other scenarios as well.

Let us assume that each column contains a program to retrieve the data. A minimum of one retrieved value per cell is needed. In many cases, multiple values are needed to render the correct data.

1. Data Retrieval by Cell

Each column’s program loops the rows in the table and retrieves the information to show, i.e., each cell is responsible for retrieving its own data.  → Minimum calls to the database are Y columns * X rows (e.g. 10 columns and 1000 rows gives 10,000 database calls).

Based on numerous reviews made by TECHNIA, this approach is heavily used in customers’ applications.

2. Data Retrieval by Column

Each column’s program makes a combined call to the database asking for the same information for all rows at once, i.e., each column is responsible for retrieving its own data.

→ Minimum calls to the database are Y columns (e.g. 10 columns and 1000 rows gives 10 database calls).

Data Retrieval by Table

Each column’s program needed calls are combined for retrieving the data, i.e., each table is responsible for retrieving its own data.

→ Minimum calls to the database are N tables (e.g. 10 columns and 1000 rows gives 1 database call).

How to Improve ENOVIA Data Retrieval

Approach 1 above can very quickly develop into a lot of calls. If the number of rows double, the number of database calls double. The same if the columns double. If both the columns and the rows double, the cells and database calls quadruple.

It might be the easiest approach from a development point of view, writing the retrieval code sequentially mixed with the rendering code, but it has a huge impact on performance.

Approach 2 is much better, letting each column make the same query/queries for all the rows at the same time. The implementation effort for this approach should not be higher than on approach number one.

It is still not optimal. Often, similar cells – or even the same calls – are made in more than one column, as part of what is going to be rendered. It would be beneficial not just to combine the select calls into one, but do not make the same select call multiple times.

Approach 3 uses as few database calls as possible to make the retrieval. In this approach, there is also the possibility not to have to make duplicate calls, as well as combining similar calls into a single call. This approach is the most complex one to design, but will give the best results in the end.

The conclusion of this is that trying to combine calls to the database to as few as possible will in most cases improve performance and system load rapidly.