Performance impact of table extensions without fields (only code)?

michael.vogel@agiles.net

Hi!

It is a known fact that due to the needed table joins a table extension can have an impact on the performance. But table extensions can also be used to store table related code - without extending the table structure. How does this impact the performance?

Or are there other recommendations of storing such code? I don't like the idea of having some "(tablename) management" codeunits.

Thanks!

Tony_NCD

Although I can not say with absolute certainty without testing the scenario, I highly doubt that it affects performance, even when you extend the table structure. The reason for the performance impact is due to the lookups, when performing any form of data related operation. This is not much different from a flowfield lookup, although it can be faster, depending on the table and fields associated.

Anyway, when NAV references the code within the object table, there will or should always be just 1 set of codes, not 1 per record, therefore, there shouldn't be any impact on performance. In other words, so long as you're not doing a GET, FIND, etc., there shouldn't be a difference in performance.

As for not liking the idea of some "(tablename) management" codeunit, I generally use just 1 "Extension" codeunit, the naming convention is part of the function itself, like T21_OnInsert, but you can break them down by department or relationships like "Sales Extension" and "Purchase Extension" as a way to keep your functionalities separated.