Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Dataverse-prestaties: schaalbare datamodellen met een slank schema, slimme relaties en indexen (AI-nasynchronisatie)

Transcript

Dataverse-prestaties: schaalbare datamodellen met een slank schema, slimme relaties en indexen (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Speaker 2: Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en
• 0:05
  Speaker 2: de mensen die de toekomst van werk vormgeven? Deze januari
• 0:09
  Speaker 2: is M365 komt terug en we pakken groter uit. Doe
• 0:12
  Speaker 2: mee aan livesessies, praktijkdemo's en krijg praktisch inzicht van MVP's
• 0:16
  Speaker 2: en experts van over de hele wereld. Geen algemene presentaties,
• 0:20
  Speaker 2: geen eindeloze modewoorden. We pakken de echte uitdagingen aan Copilot Studio,
• 0:25
  Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu IT-professional,
• 0:31
  Speaker 2: ontwikkelaar of zakelijk leider bent, er zijn sessies speciaal voor
• 0:34
  Speaker 2: jou ontworpen. Tijdens tien volle dagen kun je diverse technologieën
• 0:37
  Speaker 2: verkennen en in contact komen met een wereldwijde community. Kijk
• 0:41
  Speaker 2: live mee en neem praktische inzichten mee terug naar je organisatie.
• 0:44
  Speaker 2: Januari 2027, tien dagen, één Microsoft Community. De inschrijving is
• 0:50
  Speaker 2: nu geopend
• 0:51
  Speaker 2: Ga naar m365com.net en verzeker je vandaag nog van een plek.
• 0:56
  Speaker 2: Dat is m365com.net. Schrijf je nu in op m365com.net, dan
• 1:03
  Speaker 2: zien we je live in januari
• 1:05
  Speaker 2: Wat als de reden dat je dataverse app traag wordt
• 1:08
  Speaker 2: niet de hoeveelheid data is, maar de manier waarop je
• 1:10
  Speaker 2: relaties zijn opgezet? Vandaag gaan we in op het verborgen
• 1:14
  Speaker 2: verband tussen schemaontwerp en werkelijke responsiviteit en waarom veel powerplatformmakers
• 1:20
  Speaker 2: zich onbewust vanaf dag 1 vastzetten in slechte prestaties. De
• 1:25
  Speaker 2: verborgen prestatievalkuilen in je tabellen. Vraag je je wel eens
• 1:28
  Speaker 2: af waarom een tabel met slechts enkele duizenden rijen trager
• 1:31
  Speaker 2: aanvoelt dan een tabel met een miljoen. Het is een
• 1:33
  Speaker 2: van die momenten waarop je gevoel zegt dat het prima
• 1:35
  Speaker 2: zou moeten zijn, maar Dataverse gedraagt zich alsof het door
• 1:38
  Speaker 2: nat cement moet bewegen. De verrassende waarheid is dat het
• 1:41
  Speaker 2: niet de ruwe omvang is die je app vertraagt, maar
• 1:43
  Speaker 2: de manier waarop de tabel in eerste instantie is ontworpen.
• 1:46
  Speaker 2: En die ontwerpbeslissingen veroorzaken problemen lang voordat je tegen echte
• 1:50
  Speaker 2: platformlimieten aanloopt. Veel makers geven externe factoren de schuld. Ze
• 1:54
  Speaker 2: gaan ervan uit dat hun tenant wordt beperkt, het netwerk
• 1:57
  Speaker 2: instabiel is of dat er een verborgen opslagknelpunt in de
• 2:00
  Speaker 2: service zit. Maar in veel gevallen zijn trage formulieren, haperende
• 2:04
  Speaker 2: opzoekacties en power automate flows die steeds een time-out geven,
• 2:07
  Speaker 2: Terug te voeren op een schema dat perfect leek tijdens
• 2:10
  Speaker 2: de opbouwfase, maar zo gestructureerd was dat elke query die
• 2:13
  Speaker 2: het raakt wordt vertraagd. Als je wel eens een gebruiker
• 2:16
  Speaker 2: hebt horen klagen dat dataverse traag is zonder verdere context,
• 2:20
  Speaker 2: is de kans groot dat de echte boosdoener je tabelindeling is.
• 2:23
  Speaker 2: Zie het als een archiefkast. Als elke lade volgepropt is
• 2:26
  Speaker 2: met papieren en niets is gelabeld, maakt het niet uit
• 2:28
  Speaker 2: of er slechts 50 bestanden in zitten, je verliest alsnog
• 2:31
  Speaker 2: tijd met zoeken. Een dataverse tabel werkt op precies dezelfde manier.
• 2:35
  Speaker 2: Overladen met velden die je zelden gebruikt en aan elkaar
• 2:37
  Speaker 2: geregen met onnodige relaties, kan het zelfs eenvoudige gegevensbewerkingen tergent
• 2:41
  Speaker 2: traag maken. En in tegenstelling tot een rommelige kast, is
• 2:44
  Speaker 2: de rotzooi hier niet direct zichtbaar voor jou of de gebruiker.
• 2:46
  Speaker 2: Het enige symptoom is een toenemend prestatieverlies. Ik heb projecten
• 2:50
  Speaker 2: gezien waarbij het tabelschema aanvoelde als een verzameling van elk
• 2:53
  Speaker 2: verzoek van elke stakeholder. Een veld nodig voor interne notities
• 2:56
  Speaker 2: in drie verschillende formaten? Geregeld. Een dozijn variaties van dezelfde
• 3:00
  Speaker 2: opzoekactie voor het geval iemand die later nodig heeft? Voeg
• 3:02
  Speaker 2: het toe. Na verloop van tijd worden deze velden doodgewicht.
• 3:05
  Speaker 2: Ze worden geïndexeerd terwijl dat niet hoeft, ze vertragen invoegingen
• 3:09
  Speaker 2: en updates en ze maken de formulier UI zwaarder dan nodig.
• 3:12
  Speaker 2: Een echt voorbeeld betrof een klantentabel met meer dan 250 velden,
• 3:16
  Speaker 2: waarvan de meeste er alleen, voor de zekerheid, waren. Het resultaat,
• 3:20
  Speaker 2: een formulier dat er meer dan 12 seconden over deed
• 3:22
  Speaker 2: om te laden op een snelle verbinding. En dat was
• 3:24
  Speaker 2: nog voordat er automatisering aan te pas kwam. De eigen
• 3:26
  Speaker 2: documentatie van Microsoft zet de afwegingen bij normalisatie uiteen. Volgens
• 3:30
  Speaker 2: het boekje beschermt het opsplitsen van gegevens in veel kleinere,
• 3:33
  Speaker 2: gerelateerde tabellen tegen redundantie. In de praktijk kan over normalisatie
• 3:37
  Speaker 2: de dataverse prestaties schaden als normale bewerkingen te veel joins
• 3:41
  Speaker 2: tussen die tabellen vereisen. Elke join is extra werk voor
• 3:44
  Speaker 2: de query engine. En als je kolommen hebt die nauwelijks
• 3:47
  Speaker 2: veranderen in aparte gerelateerde tabellen... Betaal je verwerkingskosten zonder enig
• 3:51
  Speaker 2: echt voordeel. Het snoeien van niet-kritieke velden is geen glamoureus werk,
• 3:55
  Speaker 2: maar het loont snel. Identificeer kenmerken die niet worden gebruikt
• 3:58
  Speaker 2: in rapportages, zelden veranderen of elders informatie dupliceren. Behoud alleen
• 4:02
  Speaker 2: wat vandaag een echt proces dient, niet wat ooit nog
• 4:04
  Speaker 2: eens nodig zou kunnen zijn. Hetzelfde geldt voor normalisatie. Het
• 4:08
  Speaker 2: is de moeite waard om te bekijken waar je gerelateerde
• 4:09
  Speaker 2: maar weinig gebruikte gegevens kunt combineren om joints te verminderen.
• 4:12
  Speaker 2: Het doel is niet om goede ontwerpprincipes weg te gooien,
• 4:15
  Speaker 2: maar om een balans te vinden tussen theorie en hoe
• 4:17
  Speaker 2: je app daadwerkelijk draait onder belasting. De realiteit is dat
• 4:20
  Speaker 2: schaalbare prestaties niet komen door simpelweg meer resources aan dataverse
• 4:23
  Speaker 2: toe te voegen. Het begint met een schema dat is
• 4:25
  Speaker 2: ontworpen voor het doel. Slanke tabellen voeren sneller uit, formulieren
• 4:29
  Speaker 2: laden voorspelbaarder en automatisering start op tijd, zelfs als je
• 4:32
  Speaker 2: omgeving groeit. Elk onnodig veld of slecht doordachte normalisatiekeuze voegt
• 4:38
  Speaker 2: een beetje meer wrijving toe aan elke query. Na verloop
• 4:41
  Speaker 2: van tijd stapelt die wrijving zich op tot merkbare vertraging.
• 4:44
  Speaker 2: Nu de rommelfactor aan het licht is gekomen, schuilt de
• 4:47
  Speaker 2: volgende uitdaging in hoe je tabellen met elkaar interageren en
• 4:50
  Speaker 2: daar kan het ontwerp van relaties te prestaties maken of breken.
• 4:54
  Speaker 2: Wanneer relaties in wegversperringen veranderen, zijn sommige dataverse relaties als
• 4:59
  Speaker 2: kruispunten in de spits. Alles loopt op één plek vast
• 5:01
  Speaker 2: en de hele doorstroom vertraagt tot een slakkegang. Op papier
• 5:05
  Speaker 2: ziet de datastructuur er schoon en logisch uit, maar in
• 5:08
  Speaker 2: de praktijk kan één overbelast joinpunt een hele modelgestuurde app
• 5:11
  Speaker 2: op de knieën dwingen. Dit gaat niet om slechte data
• 5:14
  Speaker 2: of enorme volumes, het gaat erom hoe de relaties onder
• 5:17
  Speaker 2: de motorkap zijn verbonden. Het ontwerp van relaties kan stilletjes
• 5:20
  Speaker 2: prestatieproblemen introduceren die pas aan het licht komen bij gebruik
• 5:23
  Speaker 2: op grote schaal. In kleinere testomgevingen werken zelfs inefficiënte joins prima.
• 5:27
  Speaker 2: Rol hetzelfde ontwerp uit naar een bedrijfsomgeving met duizenden actieve
• 5:31
  Speaker 2: gebruikers en verbonden processen, en plotseling laden formulieren traag, geven
• 5:36
  Speaker 2: subgids time-outs en voelt alles wat die gekoppelde tabellen aanraakt
• 5:39
  Speaker 2: stroperig aan. Dit zijn geen mysterieuze vertragingen in de cloud,
• 5:43
  Speaker 2: het is het natuurlijke gevolg van relaties die zijn ontworpen
• 5:46
  Speaker 2: op basis van overzichtelijkheid, zonder rekening te houden met hoe
• 5:49
  Speaker 2: Dataverse Queries daadwerkelijk uitvoert. Ik heb dit zelf gezien bij
• 5:53
  Speaker 2: een project dat een veel-op-veel-relatie gebruikte om contactpersonen aan meerdere
• 5:57
  Speaker 2: serviceplannen te koppelen. Bij vroege tests met een paar honderd
• 6:00
  Speaker 2: records verliep alles soepel. Maar zodra de live dataset groeide
• 6:05
  Speaker 2: naar honderdduizenden records en gebruikers dagelijks die koppelingen raadpleegden, veranderde
• 6:10
  Speaker 2: die veel op veel tabel in het traagste onderdeel van
• 6:12
  Speaker 2: het systeem. Elke keer dat een formulier werd geladen, werden
• 6:15
  Speaker 2: complexe joins over drie tabellen geactiveerd. Elke join voegde extra
• 6:19
  Speaker 2: overhead toe totdat basisbewerkingen veel langer duurden dan verwacht. De
• 6:22
  Speaker 2: verborgen kosten zitten niet alleen in de joins zelf. Opzoekvelden
• 6:26
  Speaker 2: in dataverse kunnen trapsgewijze acties bevatten, zoals automatische toewijzingen van records,
• 6:31
  Speaker 2: verwijderingen of updates die telkens worden uitgevoerd wanneer het gekoppelde
• 6:34
  Speaker 2: record verandert. Hoewel die geweldig zijn om data synchroon te houden...
• 6:38
  Speaker 2: betekenen ze ook meer achtergrondverwerking bij elke update, zelfs voor
• 6:42
  Speaker 2: velden die niets met de hoofdtaak te maken hebben. In
• 6:45
  Speaker 2: druk bezochte tabellen kunnen die trapsgewijze acties zich snel opstapelen,
• 6:48
  Speaker 2: wat de doorvoer vermindert en interacties vertraagt zonder een duidelijke
• 6:52
  Speaker 2: aanwijsbare oorzaak. De eigen richtlijnen van Microsoft adviseren om onnodig
• 6:56
  Speaker 2: complexe joins te vermijden en dat is niet voor niets.
• 6:58
  Speaker 2: Elke extra join in een query dwingt de dataverse engine
• 7:02
  Speaker 2: om meer werk te verrichten, meer data te vertalen en
• 7:04
  Speaker 2: meer informatie in het geheugen te houden tijdens het evalueren
• 7:07
  Speaker 2: van condities. Dit is beheersbaar in kleine hoeveelheden, maar zodra
• 7:11
  Speaker 2: je meerdere veel-op-veel relaties en trapsgewijze acties in hetzelfde proces
• 7:15
  Speaker 2: gaat stapelen, schaalt de uitvoeringstijd veel sneller op dan je
• 7:18
  Speaker 2: zou verwachten. Een bijzonder verhelderend geval betrof het wijzigen van
• 7:22
  Speaker 2: een relatie van veel-op-veel naar een enkele opzoekfunctie met een
• 7:25
  Speaker 2: ondersteunend keuzeveld. De bedrijfslogica werd enigszins aangepast zodat het niet
• 7:30
  Speaker 2: langer nodig was om dynamisch meerdere gekoppelde records te achterhalen,
• 7:33
  Speaker 2: wat resulteerde in een directe reductie van 80% in de
• 7:36
  Speaker 2: laadtijd van formulieren. Die verbetering kwam niet doordat de dataset
• 7:40
  Speaker 2: kleiner werd of de hardware beter. Het was volledig te
• 7:43
  Speaker 2: danken aan het bieden van een eenvoudiger en directer pad
• 7:45
  Speaker 2: voor dataversen naar de informatie die het nodig had. Alternatieve ontwerpen,
• 7:49
  Speaker 2: zoals het platleggen van structuren, kunnen ook hun vruchten afwerpen.
• 7:52
  Speaker 2: Soms hoeft een stukje data niet in een eigen toegewezen
• 7:55
  Speaker 2: gerelateerde tabel te staan. Als het onderhoudsarm is en zelden veranderd,
• 7:59
  Speaker 2: betekent het direct opslaan in het hoofdrecord als keuzeveld 1
• 8:02
  Speaker 2: join minder bij het ophalen. Evenzo kunnen sommige koppeltabellen worden
• 8:07
  Speaker 2: vervangen door berekende of roll-up velden als ze voornamelijk worden
• 8:10
  Speaker 2: gebruikt om samengevatte informatie weer te geven. En dat houdt
• 8:13
  Speaker 2: de presentatielaag snel, terwijl zware query-operaties op de achtergrond worden vermeden.
• 8:18
  Speaker 2: De kernboodschap hier is dat het ontwerpen van relaties niet
• 8:21
  Speaker 2: alleen draait om logische helderheid of het voldoen aan normalisatiestandaarden.
• 8:25
  Speaker 2: Het draait ook om het begrijpen van de uitvoeringskosten. Elk
• 8:28
  Speaker 2: relatietype dat je kiest, verandert de manier waarop Dataverse je
• 8:32
  Speaker 2: gegevens moet ophalen, koppelen en verwerken. Je alleen concentreren op
• 8:36
  Speaker 2: hoe het schema eruit ziet zonder te kijken naar de uitvoering,
• 8:39
  Speaker 2: kan leiden tot een structuur die op papier perfect lijkt,
• 8:42
  Speaker 2: maar in de praktijk tergentraag aanvoelt. En hoewel het stroomlijnen
• 8:46
  Speaker 2: van relaties een groot deel van die verwerkings overhead wegneemt,
• 8:50
  Speaker 2: is er nog een factor die bepaalt hoe snel Dataverse reageert,
• 8:53
  Speaker 2: de indexeringsstrategie die die queries aanstuurt. Indexering, de stille prestatie multiplier.
• 8:59
  Speaker 2: Queries zijn slechts zo snel als de paden die ze
• 9:01
  Speaker 2: kunnen bewandelen. En in dataverse bepaalt indexering dat pad. De
• 9:05
  Speaker 2: meeste makers weten wel dat indexen bestaan, maar in de
• 9:08
  Speaker 2: praktijk is het een van de minst begrepen onderdelen van prestatieoptimalisatie.
• 9:12
  Speaker 2: Je kunt een schone tabelstructuur en gestroomlijnde relaties hebben, maar
• 9:16
  Speaker 2: als dataverse de benodigde records niet snel kan vinden, vertraagt
• 9:19
  Speaker 2: al het andere tot het niveau van de traagste zoekopdracht.
• 9:22
  Speaker 2: Zie het als het zoeken naar een enkele doos in
• 9:24
  Speaker 2: een enorm magazijn. Zonder enige indexering loop je van gandpad
• 9:29
  Speaker 2: naar gandpad en controleer je elke plank totdat je de
• 9:31
  Speaker 2: juiste vindt. Dat werkt misschien als het magazijn klein is,
• 9:35
  Speaker 2: maar zodra je opschalt naar miljoenen items, wordt het absurd.
• 9:38
  Speaker 2: Indexering staat gelijk aan het hebben van een nauwkeurige kaart
• 9:41
  Speaker 2: en een directe route naar de exacte plank. Hoe minder
• 9:43
  Speaker 2: werk Dataverse hoeft te doen om een record te lokaliseren,
• 9:46
  Speaker 2: hoe sneller elke weergave, elk filter en elke automatisering draait.
• 9:49
  Speaker 2: Dataverse maakt automatisch bepaalde indexen voor je aan. Voornamelijk op
• 9:53
  Speaker 2: primaire sleutels, lookups en sommige systeemkolommen. Daarom presteren nieuwe omgevingen
• 9:58
  Speaker 2: vaak prima zonder handmatige informatie. indexering... maar automatische indexering kent grenzen.
• 10:02
  Speaker 2: Complexe queries met meerdere voorwaarden, vooral op aangepaste kolommen... kunnen
• 10:07
  Speaker 2: uiteindelijk grote delen van de tabel scannen... omdat er geen
• 10:10
  Speaker 2: gerichte index is om ze te begeleiden. Dat is het
• 10:12
  Speaker 2: punt waarop je trage dashboards, vertraagde rapporten en lijstweergave ziet
• 10:16
  Speaker 2: die niet soepel laden. Het andere uiterste over indexering kan
• 10:20
  Speaker 2: net zo slecht zijn. Elke keer dat je een record invoegt,
• 10:23
  Speaker 2: bijwerkt of verwijdert, moet Dataverse alle relevante indexen bijhouden. Te
• 10:27
  Speaker 2: veel aangepaste indexen kunnen de schrijftijden verhogen en bulk updates vertragen.
• 10:33
  Speaker 2: De kunst is hier om te weten welke kolommen het
• 10:35
  Speaker 2: waard zijn om te indexeren en, net zo belangrijk, welke niet.
• 10:38
  Speaker 2: Indexen zijn het meest waardevol op velden die vaak worden
• 10:41
  Speaker 2: gebruikt in filters, sorteringen of joins, niet op velden die
• 10:44
  Speaker 2: er alleen toedoen in incidentele formulierweergave. Bijvoorbeeld, bij een servicetabel
• 10:48
  Speaker 2: met een hoog volume duurde het genereren van rapporten wel
• 10:51
  Speaker 2: 6 seconden om een gefilterde lijst voor managers weer te geven.
• 10:54
  Speaker 2: Het kernprobleem was dat het filteren plaatsvond op een aangepaste
• 10:57
  Speaker 2: kolom voor aanvraagtypes zonder specifieke index. Het toevoegen van een
• 11:01
  Speaker 2: non-clustered index aan die kolom bracht de querytijd direct terug
• 11:04
  Speaker 2: naar minder dan 200 milliseconden. Dat is geen kleine verbetering.
• 11:07
  Speaker 2: Het veranderde de ervaring van de app voor dagelijkse gebruikers volledig.
• 11:11
  Speaker 2: En het mooiste is, het vereiste geen aanpassingen aan het
• 11:13
  Speaker 2: datamodel of de UI-logica, alleen een slimmer ophaalpad. Maar achteraf
• 11:17
  Speaker 2: profiteren van die winst is niet ideaal. Het achteraf toevoegen
• 11:20
  Speaker 2: van indexen in een live systeem brengt risico's met zich mee.
• 11:24
  Speaker 2: Je moet testen op schrijfimpact, wijzigingen plannen tijdens rustige uren
• 11:28
  Speaker 2: en soms rekening houden met migratie overhead bij zeer grote tabellen.
• 11:33
  Speaker 2: Daarentegen maakt het plannen van je indexstrategie voor de livegang
• 11:36
  Speaker 2: het hele systeem veerkrachtiger. Je kunt indexen vanaf dag 1
• 11:39
  Speaker 2: koppelen aan je meest gebruikte queries, waardoor noodoplossingen voor prestaties
• 11:43
  Speaker 2: later minder nodig zijn. Een goede aanpak bij het plannen
• 11:45
  Speaker 2: van het schema is om je drukste queries in kaart
• 11:47
  Speaker 2: te brengen en te identificeren op welke velden ze vaak filteren.
• 11:50
  Speaker 2: Als je weet dat een weergave of appscherm altijd sorteert
• 11:53
  Speaker 2: op een specifieke kolom, overweeg dan om deze vanaf het
• 11:55
  Speaker 2: begin te indexeren. Hetzelfde geldt voor joinvoorwaarden in relaties waarvan
• 11:59
  Speaker 2: je weet dat ze essentieel zijn voor de workflow van
• 12:00
  Speaker 2: de app. Controleer daarna periodiek de index gebruikstatistieken om kandidaten
• 12:04
  Speaker 2: te vinden die je kunt verwijderen omdat ze zelden worden
• 12:07
  Speaker 2: gebruikt in echte queries. Indexering is niet opvallend en verschijnt
• 12:10
  Speaker 2: niet in de UI zoals een nieuw formulier of dashboard,
• 12:13
  Speaker 2: maar het is een stille groeifactor. Elke geoptimaliseerde query profiteert
• 12:17
  Speaker 2: ervan en elke slecht geïndexeerde query wordt een blok aan
• 12:20
  Speaker 2: het been naarmate je dataset groeit. Een effectieve indexstrategie zorgt
• 12:24
  Speaker 2: voor prestatieruimte en verandert query uitvoering van een potentieel knelpunt
• 12:28
  Speaker 2: in een betrouwbare kracht. Maar er is nog één knop
• 12:30
  Speaker 2: om aan te draaien. Om dataverse echt snel te houden
• 12:34
  Speaker 2: op schaal, moet je verschuiven van het oplossen van knelpunten
• 12:37
  Speaker 2: naar het ontwerpen op een manier die ze voorkomt. Van
• 12:41
  Speaker 2: reactieve oplossingen naar proactieve architectuur. De meeste prestatieverbeteringen in dataverse
• 12:46
  Speaker 2: voelen als brandjes blussen. Een gebruiker meldt trage formulieren, je
• 12:49
  Speaker 2: voert wat checks uit, brengt gerichte wijzigingen aan en hoopt
• 12:51
  Speaker 2: dat het probleem is opgelost. Maar wat als je op
• 12:53
  Speaker 2: een manier zou kunnen bouwen die voorkomt dat die problemen
• 12:56
  Speaker 2: überhaupt ontstaan? De stille waarheid is dat de snelste, meest
• 12:59
  Speaker 2: stabiele dataverse apps niet alleen goed zijn afgesteld. Ze zijn
• 13:02
  Speaker 2: vanaf dag 1 ontworpen met schaalbaarheid in het achterhoofd. Vroege
• 13:05
  Speaker 2: architecturale planning is de goedkoopste prestatieboost die je ooit zult realiseren.
• 13:10
  Speaker 2: Het gaat er niet om voor de zekerheid extra lagen
• 13:13
  Speaker 2: toe te voegen, maar om na te denken over hoe
• 13:15
  Speaker 2: je tabellen, relaties en indexen zich gedragen onder volledige productiebelasting.
• 13:20
  Speaker 2: In de bouwfase zijn alle wijzigingen aan beslissingen goedkoop. Zodra
• 13:24
  Speaker 2: de app live is, kan dezelfde wijziging betekenen dat tientallen flows,
• 13:27
  Speaker 2: dashboards en modelgestuurde formulieren moeten worden aangepast. Het verschil in
• 13:30
  Speaker 2: inspanning is dag en nacht. Ik heb gewerkt met teams
• 13:33
  Speaker 2: die pas vlak voor de livegang aan prestatietesten toekwamen. Alles
• 13:36
  Speaker 2: was logisch opgebouwd, zag er in het schema netjes uit
• 13:39
  Speaker 2: en werkte prima in de acceptatietesten. Maar daarna begon een
• 13:42
  Speaker 2: analyserapport de minuten te laden, Power Automate flows kregen time-outs
• 13:46
  Speaker 2: en bepaalde formulieren openden slechts de helft van de tijd.
• 13:49
  Speaker 2: In één geval moest een kernapp voor planning volledig worden
• 13:52
  Speaker 2: gesloopt en herbouwd, omdat meerdere belangrijke queries afhankelijk waren van
• 13:56
  Speaker 2: niet geïndexeerde velden in veel op veel relaties. De herbouw
• 13:59
  Speaker 2: stelde de livegang met drie maanden uit en kostte weken
• 14:02
  Speaker 2: aan uren voor ontwikkelaars en testers. De sleutel om dat
• 14:05
  Speaker 2: scenario te vermijden is prestaties en ontwerp vereisten te maken,
• 14:09
  Speaker 2: geen bijzaak. Dat betekent dat je indexering plant op hetzelfde
• 14:13
  Speaker 2: moment dat je de tabellen ontwerpt, weet welke velden in
• 14:15
  Speaker 2: elk filter komen en zorgt dat ze efficiënt doorzoekbaar zijn.
• 14:18
  Speaker 2: Het betekent dat je de verleiding moet weerstaan om tijdens
• 14:21
  Speaker 2: het prototypen voor de zekerheid tientallen velden toe te voegen,
• 14:24
  Speaker 2: omdat elk veld formulieren en transacties vertragen. En het betekent
• 14:27
  Speaker 2: dat je relaties modeleert op basis van hoe ze op
• 14:29
  Speaker 2: schaal presteren, niet alleen op hoe netjes ze er uitzien
• 14:32
  Speaker 2: in een diagram tijdens een workshop. Wanneer je prestaties als
• 14:35
  Speaker 2: onderdeel van de architectuur behandelt, ben je veel minder afhankelijk
• 14:37
  Speaker 2: van probleemoplossing na de implementatie. Je ontdekt potentiële knelpunten wanneer
• 14:41
  Speaker 2: het nog makkelijk is om van koers te veranderen. Als
• 14:43
  Speaker 2: een bepaald relatiemodel joins in grote datasets vertraagt, zoek je
• 14:47
  Speaker 2: naar een alternatieve structuur voordat het een live systeem aanstuurt.
• 14:50
  Speaker 2: Als een index een veelgebruikte weergave direct kan maken, voeg
• 14:53
  Speaker 2: je deze toe voordat de weergave bedrijfscritisch wordt. Dat is
• 14:55
  Speaker 2: veel eenvoudiger dan aan zakelijke gebruikers uit te leggen waarom
• 14:58
  Speaker 2: hun app nu anders werkt omdat je iets moest repareren
• 15:00
  Speaker 2: waarvan zij niet wisten dat het kapot was. Er zijn
• 15:02
  Speaker 2: tools in het Microsoft-ecosysteem die deze proactieve mentaliteit veel makkelijker
• 15:06
  Speaker 2: toepasbaar maken. De Solution Checkers kent je omgeving en wijst
• 15:10
  Speaker 2: op patronen waarvan bekend is dat ze prestatieproblemen kunnen veroorzaken.
• 15:13
  Speaker 2: Prestatie-inzichten in het Power Platform Beheer Centrum helpen je trage
• 15:17
  Speaker 2: queries op te sporen, laadtijden van formulieren bij te houden
• 15:20
  Speaker 2: en te identificeren waar ophalen of renderen wordt opgehouden. Deze
• 15:24
  Speaker 2: tools uitvoeren tijdens de bouw en voor grote releases is
• 15:26
  Speaker 2: de beste garantie voor prestaties, zonder dat live gebruikers de
• 15:30
  Speaker 2: testers worden. De opbrengst van deze werkwijze is simpel. Apps
• 15:33
  Speaker 2: die gebouwd zijn met proactief denken over prestaties, schalen doorgaans
• 15:37
  Speaker 2: soepel met minimale aanpassingen. Wanneer het data volume groeit, stuiten
• 15:41
  Speaker 2: ze niet plotseling op onverwachte limieten. Wanneer nieuwe functies worden toegevoegd,
• 15:44
  Speaker 2: komt niets tot stilstand omdat het oorspronkelijke ontwerp ruimte liet.