Dataverse Alternate Keys: doporučení pro pozdě doplněné externí ID

Krátké doporučení

Nedělej z pozdě doplněného externího ID Alternate Key automaticky. Pro většinu integrací je lepší mít samostatný stabilní korelační/idempotency klíč známý už před Create a externí ID ukládat jako běžný sloupec. Alternate Key z externího ID použij až tehdy, když ho opravdu potřebuješ pro Dataverse-native adresování řádku, Upsert, lookupy nebo platformově vynucenou unikátnost.

Co je ověřené v Microsoft dokumentaci

Co je inference pro tento scénář

Microsoft dokumentace explicitně nepopisuje všechny detaily scénáře „create s prázdným/null external ID → pozdější update na non-null alternate key“. Praktický závěr proto rozlišuj takto:

• Create bez známého externího ID: pokud alternate-key sloupec není vyplněný, nepomůže s idempotencí počátečního vytvoření.
• Pozdější Update external ID: zápis hodnoty do sloupce zahrnutého v Alternate Key musí udržet unikátní index; to je write-path režie navíc proti obyčejnému sloupci.
• Budoucí lookup/upsert přes Alternate Key: tady je hlavní přínos — indexované adresování a platformová kontrola unikátnosti.
• NULL/prázdné hodnoty: oficiální Microsoft Learn dokumentace v použitých zdrojích nepokrývá přesnou NULL semantiku Alternate Keys, takže ji ověř v pre-produkci na vlastním schématu a datech.

Odpovědi na původní otázky

1. Je návrh výkonově přijatelný?
2. Pro malé a střední objemy může být přijatelný.

3. Pro high-throughput integraci to není dobrý default, pokud externí ID nepotřebuješ pro Upsert/adresování.

4. Co bude stát víc: create, update, nebo upsert/lookups?

5. Create, pokud znáš, že řádek je nový, je nejčistší cesta.
6. Pozdější Update alternate-key sloupce nese index/unikátnost režii.
7. Upsert přes alternate key je prakticky nejdražší kandidát proti čistému Create, protože Microsoft u Upsert explicitně uvádí performance penalty.

8. Lookupy přes alternate key jsou naopak oblast, kde index pomáhá.

9. Má být externí ID Alternate Key?

10. Ano, pokud ho budeš často používat k Dataverse adresování, Upsert, matching nebo chceš platformově vynutit unikátnost.

11. Ne jako default, pokud ho jen ukládáš po callbacku a řádek už znáš přes Dataverse GUID/korelační ID.

12. Doporučení pro high-throughput integrace

13. Použij stabilní idempotency/correlation key známý před Create.
14. Když je řádek určitě nový, používej Create, ne Upsert.
15. Externí ID po callbacku ukládej úzkým Update jen na známý řádek.
16. Alternate Key přidej až po jasném důvodu: časté lookupy/upserty, unikátnost nebo integrační adresování.

17. Omez synchronní plug-iny, workflow a business logiku na create/update cestě.

18. Co měřit v pre-produkci

19. Create latency/throughput bez alternate key vs. s alternate key definicí.
20. Latenci pozdějšího Update, který doplňuje externí ID.
21. Upsert latency/throughput přes alternate key proti čistému Create + Update.
22. Chyby unikátnosti, retry/replay scénáře async callbacku.
23. Dopad batch/parallel zpracování a service protection limitů.
24. Chování prázdných/null hodnot přesně pro daný sloupec a schéma.

Implementační checklist

• [ ] Rozhodni, který klíč je známý před Create a použij ho pro idempotenci.
• [ ] Externí ID označ jako Alternate Key jen při reálné potřebě Upsert/adresování/unikátnosti.
• [ ] Ověř, že string ID nepoužívá znaky problematické pro Web API alternate-key adresování.
• [ ] Změř create/update/upsert varianty na datovém objemu blízkém produkci.
• [ ] Připrav retry logiku na duplicate/conflict chyby a throttling.

Oficiální Microsoft zdroje

• Work with alternate keys
• Use an alternate key to reference a record
• Use Upsert to create or update a record
• Optimize performance for Create and Update operations
• Retrieve a table row using the Web API — retrieve using an alternate key

Kontrolní poznámka

Tento text záměrně odděluje věci přímo doložené Microsoft dokumentací od praktické inference pro konkrétní návrh integrace s pozdě doplněným externím ID.