bcquality/community/knowledge/performance/choose-maintainsiftindex-by-read-write-ratio.md
Jesper Schulz-Wedde 9a4198eb28 Add [all] sentinel to bc-version; apply to version-agnostic knowledge
Most of the corpus — FindSet/SetLoadFields/CalcFields patterns, permission
sets, SingleInstance codeunits, DataClassification, IsolatedStorage,
transaction scope, SecretText — describes BC platform behaviour that is
identical across supported versions. The seed [26..28] range on every
file implied a version-specificity the content does not actually have,
and there was no way to express "applies to every version" in the
schema the way [w1] and [all] already do for countries and
application-area.

Extend the v1 schema with a universal sentinel for bc-version, parallel
to the sentinels already defined for the other dimensions:

  bc-version: [all]         # applies to every BC version

[all] is mutually exclusive with explicit versions. Range shorthand
([26..28]) and explicit lists ([26, 27, 28]) continue to work for files
genuinely tied to a version-gated API or deprecation.

Update read.md (field definition, matching semantics, partial-context
rule), write.md (default to [all], use ranges only with a concrete
reason), README.md (frontmatter example), and the CI validator. All
forty existing knowledge files and the three action skills convert to
[all]; none of the current content is version-gated. Validator passes.
2026-04-23 16:00:03 +02:00

1.7 KiB

bc-version domain keywords technologies countries application-area
all
performance
maintainsiftindex
sift
calcsums
flowfield
write-cost
al
w1
all

Choose MaintainSIFTIndex by read-write ratio

Seed article. Ported from BC Code Intelligence to seed the community corpus. Community contributors are invited to expand or refine.

Description

MaintainSIFTIndex on a key decides whether the SIFT aggregate structure is updated on every INSERT, MODIFY, and DELETE that touches the key's fields. With Yes, CalcSums and FlowField reads are immediate — but every write pays the cost of updating the aggregate. With No, writes are cheaper but the first aggregate read after a change has to rebuild. Neither value is universally correct; the right choice depends on how often the aggregate is read versus how often the underlying rows are written.

Best Practice

Measure read-to-write ratios for the key's SIFT fields under realistic workloads. Set MaintainSIFTIndex = Yes only on keys whose aggregates are read far more often than the rows are written (reporting keys on reference tables, dashboards). Set No on keys whose rows are written heavily and whose aggregates are read rarely (transactional ledger entries, import-staging tables).

See sample: choose-maintainsiftindex-by-read-write-ratio.good.al.

Anti Pattern

Leaving MaintainSIFTIndex = Yes on every key by reflex or convenience. On write-heavy tables the cumulative cost turns every INSERT or MODIFY into several additional aggregate updates, and the impact compounds in batch imports and posting routines — often without any code-review signal that the property is the cause.