实际操作中最常见的错误是从数据库中检索数据的方式，尤其是过度使用数据库调用。即使单个数据库调用可能非常简单并且可能只需要一毫秒或几毫秒即可完成，当它与一个大数字相乘时，它会立即增长到几秒钟。
首先，对达索系统ENOVIA数据库的调用有其自身的静态开销，每次调用都必须承担，其次，数据库一次对多个对象执行相同查询通常更容易且总体上消耗更少，而不是必须为每个单个对象一遍又一遍地重做相同的查询。
低效数据检索示例
下面的示例试图通过以不同的方式进行实现来说明差异可能是什么，即使用户的视觉最终结果是相同的。
在此示例中，使用了包含 Y 列和 X 行的表，但同样的数据检索思想也适用于许多其他场景。
让我们假设每一列都包含一个检索数据的程序。每个单元格至少需要一个检索值。在许多情况下，可能需要多个值来呈现正确的数据。
方法1）每个单元格：
每列的程序循环表中的行并检索要显示的信息，即每个单元格负责检索自己的数据。→ 对数据库的最小调用是 Y 列 * X 行（例如，10 列和 1000 行给出 10.000 次数据库调用）。
方法2）每列：
每列的程序对数据库进行一次组合调用，要求同时为所有行提供相同的信息，即每列负责检索自己的数据。
→ 对数据库的最小调用是 Y 列（例如 10 列和 1000 行给出 10 次数据库调用）。
方法3）每个表：
每个列的程序需要调用组合在一起以检索数据，即每个表负责检索自己的数据。
→ 对数据库的最小调用是 N 个表（例如 10 列和 1000 行给出 1 个数据库调用）。
结论
上面的方法 1可以很快增长为大量调用。如果行数加倍，则数据库调用次数加倍，如果列数加倍，则相同。如果列和行都加倍，则单元格因此数据库调用将加倍。
从开发的角度来看，这可能是最简单的方法，以顺序方式编写检索代码与渲染代码混合，但它对性能有巨大影响。
第二种方法要好得多，让每一列同时对所有行进行相同的查询/查询。这种方法的实施工作不应高于方法一。
它仍然不是最优的。作为将要呈现的内容的一部分，通常在不止一列中进行相似甚至相同的调用。不仅将选择调用合并为一个，而且不要多次进行相同的选择调用，这将是有益的。
第三种方法使用尽可能少的数据库调用来进行检索。在这种方法中，也有可能不必进行重复调用以及组合类似的调用。这种方法是最复杂的设计方法，但最终会得到最好的结果。
得出的结论是，尝试尽可能少地组合对数据库的调用将在大多数情况下快速提高性能和系统负载。
