Bucket number and SIFT table

The first column of the SIFT table is always named bucket. After the bucket table are the set of key columns that named in the following format f<field>. The <field> represents the Field No. in the table. After the f-columns are the s-columns, which represent the SumIndexField in the associated table. The precalculated totals are stored the s-columns.

(Click to enlarge)

Every bucket number in a SIFT table has a bucket number that corresponds to its SIFT level. The following example shows the relationship between SIFT levels and bucket find in the SIFT table.

As shown in the example, bucket 0 only contains 1 record, which is the grand total for the SumIndexField. Please take note that only 1 record will exist in bucket 0 for each SIFT table. Bucket 0 is not activated by default because it will cause performance issue during update. I have activated the SIFT Level 0 in this example for demo purposes.

(Click to enlarge)

SumIndexFields and SQL Server

When you add SumIndexFields to a key in Navision table, Navision will create additional table in SQL Server, which is known as SIFT table to store the pre-calculated value for the SumIndexFields. SIFT table is a term used in Navision. In fact, the SIFT table is just an ordinary table in SQL Server. The SIFT table is named with the following naming convention:

<company name>$<table id>$<internal id>

The internal id always starts with zero and increases by one for any additional key that contains SumIndexFields.

For example, G/L Entry table in Navision has four keys with SumIndexFields. This will causes Navision to create four table in SQL Server.
Cronus$17$0
Cronus$17$1
Cronus$17$2
Cronus$17$3



If order for Navision to maintain a SIFT table for a key, the key must meet the following 3 criterias:
1) Enabled
2) Contains SumIndexFields
3) MaintainSIFTIndex is selected


If either one of these criterias is not met, Navision will not maintain a SIFT table for the key. Now, let's do a very quick experiment. I am going to disable the MaintainSIFTIndex option for the 2nd SIFTIndex key and see what will happens to the SIFT tables in SQL Server.




Once I disabled the MaintainSIFTIndex option and save the table, one SIFT table has been removed from the SQL Server.





Please note that I diabled the MaintainSIFTIndex option for the 2nd SIFTIndex key but the SIFT Table that removed by Navision is Cronus$17$3, which was originally the SIFT table for the 4th SIFTIndex key. This shows that the internal id in the SIFT Table naming will always in sequence. Let's have a look at the SIFT table's structure that I captured before and after disabling the MaintainSIFTIndex option.


Cronus$17$1 and Cronus$17$2 before disabling MaintainSIFTIndex option



Cronus$17$1 and Cronus$17$2 after disabling MaintainSIFTIndex option


After disabling the 2nd SIFTIndex key, SIFT Tabel for the 2nd SIFTIndex key has been removed. The 3rd SIFTIndex key has been created as Cronus$17$1 while the 4th SIFTIndex key has been created as Cronus$17$2. I am not sure whether Navision has recreated the SIFT tables or just rename them.

SIFT helps in returning summed values very fast but it will slow down data insertion and modification. Whenever you do an INSERT, UPDATE or DELETE on tables with MaintainSIFTIndex enabled, Navision (more specifically, triggers in SQL Server table) will need to update the SIFT tables. This will add a lot of overhead to the server, which will cause slowdown the server performance. If you disable the MaintainSIFTIndex option, Navision will not give you error. If the MaintainSIFTIndex option is not enabled, Navision will calculate the value from the source table with the SELECT SUM sql statement. You system will still work. So, how ? Is that means we cannot enable the MaintainSIFTIndex option in Navision SQL Server Option ?

The answer is No. To get the maximum benefits from the SIFT technology, you can to enable the MaintainSIFTIndex selectively. Using SIFT tables can improve response time significantly on source tables that contain many records. However, on tables with not many records, the response time is similar as you are calculating it from the source table. As a general rules of thumb, do not maintain SIFT Indexes on small tables and temporary tables (eg. Sales Line, Purchase Line, Warehouse Activity Line, etc.) because it is not worth the additional overhead to maintain the SIFT tables but not getting significant performance improvement on small tables.