Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Prestazioni di Dataverse: modelli dati scalabili con schema snello, relazioni intelligenti e indici (Doppiaggio IA)

Transcript

Prestazioni di Dataverse: modelli dati scalabili con schema snello, relazioni intelligenti e indici (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per 10 giorni di Microsoft 365, Copilot IA, Azure
0:04
Speaker 2: e le persone che plasmano il futuro del lavoro? Questo gennaio,
0:09
Speaker 2: M365 corritorna e puntiamo ancora più. In alto, unisciti a
0:13
Speaker 2: noi per sessioni dal vivo, demo reali e conoscenze pratiche
0:16
Speaker 2: da MVP ed esperti del settore in tutto il mondo.
0:18
Speaker 2: Niente sle generiche, niente infiniti gergitecno. Affronteremo le sfide reali.
0:23
Speaker 2: Copilot Studio, agenti IA, Fabric, Sicurezza, Governance e Automazione. Che
0:30
Speaker 2: tu sia un professionista IT, uno sviluppatore o un leader aziendale,
0:33
Speaker 2: ci sono sessioni pensate per te. Con 10 giorni interi
0:36
Speaker 2: potrai esplorare molteplici tecnologie e connetterti con una community globale.
0:41
Speaker 2: Segui dal vivo e porta intuizioni pratiche nella tua organizzazione.
0:45
Speaker 2: Gennaio 2027, 10 giorni, unica community Microsoft. Le iscrizioni sono aperte.
0:51
Speaker 2: Vai su m365con. net e assicurati il tuo posto oggi stesso. m365con. net. it
0:59
Speaker 2: scriviti ora su m365com. net ci vediamo dal vivo a gennaio
1:05
Speaker 3: e se il motivo per cui la tua app Dataverse
1:07
Speaker 3: rallenta drasticamente non fosse la dimensione dei dati ma come
1:10
Speaker 3: sono collegate le relazioni oggi analizzeremo il legame nascosto tra
1:14
Speaker 3: la progettazione dello schema e la reattività reale e perché
1:17
Speaker 3: molti creatori Power Platform si condannano inconsapevolmente a prestazioni scadenti
1:22
Speaker 3: fin dal primo giorno le trappole nascoste per le prestazioni
1:26
Speaker 3: nelle tue tabelle Si è mai chiesto perché una tabella
1:29
Speaker 3: con poche migliaia di righe sembra più lenta di una
1:31
Speaker 3: con un milione? Con un milione. È uno di quei
1:33
Speaker 3: momenti in cui il tuo istinto ti dice che dovrebbe
1:35
Speaker 3: andare bene, ma Dataverse sembra muoversi nel cemento fresco. La
1:40
Speaker 3: sorprendente verità è che non è la dimensione grezza a
1:42
Speaker 3: rallentare la tua app, ma il modo in cui la
1:43
Speaker 3: tabella è stata progettata fin dall'inizio. E quelle decisioni di
1:47
Speaker 3: design iniziano a causare problemi molto prima di raggiungere i
1:50
Speaker 3: limiti reali della piattaforma. Molti creatori danno la colpa a
1:53
Speaker 3: fattori esterni. Presumono che il loro tenant sia limitato, la
1:56
Speaker 3: rete instabile, o che ci sia un collo di bottiglia
1:58
Speaker 3: nascosto nell'archiviazione del servizio. Ma in molti casi quei moduli lenti,
2:02
Speaker 3: le ricerche in ritardo e i flussi Power Automate che
2:05
Speaker 3: vanno in timeout possono essere ricondotti a uno schema che
2:08
Speaker 3: sembrava perfetto nella fase di costruzione ma era strutturato in
2:11
Speaker 3: modo da rallentare ogni singola query. Se un utente ti
2:15
Speaker 3: ha mai lamentato che data averse lento senza aggiungere dettagli
2:18
Speaker 3: c'è una buona probabilità che il vero colpevole sia il
2:21
Speaker 3: layout della tua tabella. pensalo come uno schedario se ogni
2:25
Speaker 3: cassetto è pieno di foglie nulla etichettato non importa se
2:28
Speaker 3: ci sono solo 50 file all'interno perderai comunque tempo a
2:31
Speaker 3: cercare una tabella data versa funziona allo stesso modo gonfia
2:35
Speaker 3: di campi chiusi raramente cucita insieme con relazioni inutili può
2:38
Speaker 3: far rallentare anche le operazioni sui dati più semplici e
2:42
Speaker 3: a differenza di un armadio in disordine qui il caos
2:44
Speaker 3: non è immediatamente visibile a te o all'utente l'unico sintomo
2:47
Speaker 3: è un crescente calo delle prestazioni Ho visto progetti in
2:50
Speaker 3: cui lo schema delle tabelle sembrava una raccolta dei successi
2:52
Speaker 3: di ogni richiesta, di ogni stakeholder. Ah, serve un campo
2:56
Speaker 3: per le note interne in tre formati diversi. Fatto. Una
2:59
Speaker 3: dozzina di varianti della stessa ricerca nel caso servisse in futuro. Aggiungiamola.
3:03
Speaker 3: Nel tempo questi campi diventano solo zavorra. Vengono indicizzati inutilmente,
3:06
Speaker 3: rallentano inserimenti e aggiornamenti e appesantiscono l'interfaccia utente oltre il necessario.
3:12
Speaker 3: Un esempio reale riguardava una tabella clienti con più di
3:15
Speaker 3: 250 campi, la maggior parte dei quali esisteva solo per sicurezza.
3:19
Speaker 3: In risultato, modulo che impiegava oltre 12 secondi per caricarsi
3:22
Speaker 3: su una connessione ad alta velocità. E questo prima ancora
3:24
Speaker 3: che entrasse in gioco l'automazione. La documentazione di Microsoft stessa
3:27
Speaker 3: chiarisce i compromessi nella normalizzazione. Secondo il manuale, suddivide le
3:31
Speaker 3: dati in molte tabelle correlate e più piccole protegge dalla ridondanza.
3:35
Speaker 3: In pratica, un'eccessiva normalizzazione può danneggiare le prestazioni di Dataverse
3:39
Speaker 3: se le operazioni comuni richiedono troppi join tra le tabelle.
3:43
Speaker 3: Ogni join è lavoro extra per il motore di query.
3:46
Speaker 3: E se hai colonne che cambiano raramente archiviate in tabelle
3:48
Speaker 3: correlate e separate paghi un costo di elaborazione senza alcun
3:50
Speaker 3: beneficio reale. Eliminare i campi non critici non è un
3:54
Speaker 3: lavoro entusiasmante ma ripaga rapidamente. Identifica gli attributi non usati
3:58
Speaker 3: nei report che cambiano raramente o che duplicano informazioni altrove.
4:02
Speaker 3: Conserva solo ciò che serve a un processo attuale, non
4:04
Speaker 3: ciò che potrebbe servire un giorno. Lo stesso vale per
4:06
Speaker 3: la normalizzazione. Ora vale la pena verificare dove puoi combinare
4:09
Speaker 3: dati correlati ma a bassa attività per ridurre i join.
4:12
Speaker 3: L'obiettivo non è abbandonare i buoni principi design, ma trovare
4:15
Speaker 3: un equilibrio tra teoria e il modo in cui l'app
4:17
Speaker 3: gira sotto carico. La realtà è che le prestazioni scalabili
4:20
Speaker 3: non si ottengono aggiungendo più risorse a Dataverse. Iniziano con
4:24
Speaker 3: uno scamo progettato per uno scopo. Le tabelle snelle vengono
4:27
Speaker 3: eseguite più velocemente, i moduli si caricano in modo prevedibile
4:30
Speaker 3: e l'automazione si attiva puntualmente anche quando l'ambiente cresce. Ogni
4:34
Speaker 3: campo non necessario o scelta di normalizzazione poco oculata aggiunge
4:38
Speaker 3: un po' di attrito a ogni query. Nel tempo, quell'attrito
4:42
Speaker 3: si accumula diventando un ritardo evidente. Ora che il fattore
4:45
Speaker 3: disordine è emerso, la sfida è successiva. Si nasconde nel
4:48
Speaker 3: modo in cui le tabelle interagiscono tra loro, ed è
4:50
Speaker 3: qui che il design delle relazioni può determinare le prestazioni.
4:55
Speaker 3: Quando le relazioni diventano ostacoli, alcune relazioni di dataversa sono
4:57
Speaker 3: come incroci nell'ora di punta, e tutto si blocca in
5:01
Speaker 3: un punto, l'intero flusso rallenta fino a trascinarsi. Sulla carta,
5:05
Speaker 3: la struttura dei dati sembra pulita. È logica, ma in
5:08
Speaker 3: pratica un singolo punto di join sovraccarico può mettere in
5:10
Speaker 3: ginocchio un'intera app basata su modelli. Non si tratta di
5:13
Speaker 3: dati errati o volumi enormi, ma di come le relazioni
5:16
Speaker 3: sono strutturate internamente. La progettazione delle relazioni può introdurre silenziosamente
5:21
Speaker 3: problemi di prestazioni che emergono solo su scala reale. In
5:24
Speaker 3: ambienti di test più piccoli anche i join efficienti funzionano bene.
5:27
Speaker 3: Estendi lo stesso design a un ambiente aziendale con migliaia
5:30
Speaker 3: di utenti attivi e processi interconnessi e improvvisamente i moduli
5:33
Speaker 3: impiegano secondi a caricarsi, le griglie vanno in timeout e
5:36
Speaker 3: tutto ciò che tocca a quelle tabelle collegate risulta lento.
5:42
Speaker 3: Non si tratta di misteriosi rallentamenti del cloud ma del
5:44
Speaker 3: risultato naturale di relazioni progettate per chiarezza senza considerare come
5:48
Speaker 3: Dataverse esegua effettivamente le query. L'ho visto di persone in
5:53
Speaker 3: un progetto che utilizzava una relazione molti a molti per
5:56
Speaker 3: collegare i contatti a più piani di servizio. Nei primi
5:59
Speaker 3: test con poche centinaia di record tutto procedeva senza intoppi.
6:03
Speaker 3: Ma quando il set di dati reale è cresciuto a
6:05
Speaker 3: centinaia di migliaia di record e gli utenti interrogavano quei
6:08
Speaker 3: collegamenti quotidianamente, quella tabella, molti a molti, è diventata la
6:11
Speaker 3: parte più lenta del sistema. Ogni caricamento di modulo attivava
6:15
Speaker 3: join complessi su tre tabelle e ogni join aggiungeva ulteriore
6:18
Speaker 3: sovraccarico finché le operazioni di base non richiedevano molto più
6:21
Speaker 3: tempo del previsto. Il costo nascosto non risiede solo nei
6:24
Speaker 3: join stessi. Campi di ricerca in Dataverse possono comportare comportamenti
6:28
Speaker 3: a cascata come riassegnazioni automatiche, eliminazioni e aggiornamenti che vengono
6:31
Speaker 3: eseguiti ogni volta che il record collegato cambia. Sebbene siano
6:35
Speaker 3: ottimi per mantenere i dati sincronizzati, significano anche più elaborazione
6:39
Speaker 3: in background a ogni aggiornamento, anche per campi non correlati
6:42
Speaker 3: all'operazione principale. Nelle tabelle ad alta attività, quelle cascate possono
6:47
Speaker 3: accumularsi rapidamente riducendo il throughput e rallentando le interazioni senza
6:51
Speaker 3: un trigger visibile evidente Le linee guida di Microsoft raccomandano
6:55
Speaker 3: di evitare join complessi non necessari e per una buona ragione.
6:59
Speaker 3: Ogni join aggiuntivo in una query costringe il motore di
7:01
Speaker 3: Dataverse a lavorare di più, elaborare più dati e mantenere
7:04
Speaker 3: più informazioni in memoria mentre valuta le condizioni. Questo è
7:09
Speaker 3: gestibile in piccole dosi, ma una volta che si inizia
7:11
Speaker 3: a sovrapporre più relazioni molti a molti e cascate nello
7:14
Speaker 3: stesso processo, il tempo di esecuzione scala molto più velocemente
7:17
Speaker 3: di quanto ci si aspetterebbe. Un caso particolarmente rivelatore ha
7:21
Speaker 3: comportato la modifica di una relazione da molti a molti
7:23
Speaker 3: a una simbola ricerca con un campo di scelta di supporto.
7:27
Speaker 3: La logica di business è stata leggermente rielaborata in modo
7:29
Speaker 3: da non richiedere la risoluzione dinamica di più record collegati
7:32
Speaker 3: e il risultato è stata una riduzione immediata dell'80% al
7:35
Speaker 3: tempo di caricamento del modulo. Quel miglioramento non è avvenuto
7:39
Speaker 3: perché il set di dati si è ridotto, l'hardware è migliorato.
7:42
Speaker 3: È stato interamente merito del fatto di aver dato data
7:44
Speaker 3: verso un percorso più semplice e diretto verso le informazioni
7:46
Speaker 3: di cui aveva bisogno. Anche progetti alternativi come le strutture
7:49
Speaker 3: appiattite possono dare i loro frutti. A volte un dato
7:52
Speaker 3: non ha bisogno di risiedere nella sua tabella dedicata e correlata.
7:56
Speaker 3: Se richiede poca manutenzione cambia raramente. Memorizzarlo direttamente nel record
8:00
Speaker 3: principale come campo di scelta significa un join in meno
8:03
Speaker 3: durante il recupero. Analogamente alcune tabelle di collegamento possono essere
8:08
Speaker 3: sostituite da campi calcolati di riepilogo se sono utilizzate principalmente
8:11
Speaker 3: per visualizzare informazioni riassuntive. E questo mantiene veloce il livello
8:14
Speaker 3: di presentazione evitando pesanti operazioni di query in background. Il
8:19
Speaker 3: punto fondamentale è che la progettazione delle relazioni non riguarda
8:22
Speaker 3: solo la chiarezza logica o il rispetto degli standard di normalizzazione.
8:25
Speaker 3: Si tratta anche di comprendere il costo dell'esecuzione. Ogni tipo
8:29
Speaker 3: di relazione che scegli cambia il modo in cui Dataverse
8:31
Speaker 3: deve recuperare, unire ed elaborare i tuoi dati. Concentrarsi solo
8:35
Speaker 3: sull'aspetto dello schema senza considerare come funziona può lasciarti con
8:39
Speaker 3: una struttura che ha perfettamente senso sulla carta ma che
8:41
Speaker 3: risulta terribilmente lenta in produzione. E mentre la semplificazione delle
8:46
Speaker 3: relazioni rimuove gran parte... di quel sovraccarico di elaborazione, c'è
8:49
Speaker 3: ancora un altro fattore che decide quanto velocemente risponde Dataverse
8:52
Speaker 3: alla strategia di indicizzazione che guida quelle query. Indicizzazione, silenzioso
8:58
Speaker 3: moltiplicatore di prestazioni. Le query sono veloci solo quanto i
9:01
Speaker 3: percorsi che possono seguire, e in Dataverse l'indicizzazione decide quel percorso.
9:05
Speaker 3: La maggior parte dei creatori è consapevole dell'esistenza degli indici,
9:08
Speaker 3: ma in pratica è una delle parti meno comprese dell'ottimizzazione
9:11
Speaker 3: delle prestazioni. Puoi avere una struttura di tabelle pulite e
9:14
Speaker 3: relazioni snelle, ma se Dataverse ha Non riesce a trovare
9:17
Speaker 3: rapidamente i record necessari, tutto il resto rallenta per adeguarsi
9:20
Speaker 3: alla ricerca più lenta. Immaginalo come cercare un singolo pacco
9:24
Speaker 3: in un magazzino enorme. Senza alcuna indicizzazione, cammini da una
9:28
Speaker 3: corsia all'altra controllando ogni scaffale finché non individui quello giusto.
9:33
Speaker 3: Questo funziona quando il magazzino è piccolo, ma una volta
9:35
Speaker 3: che si scala milioni di articoli diventa assurdo. L'indicizzazione equivale
9:39
Speaker 3: ad avere una mappa precisa e un percorso diretto verso
9:42
Speaker 3: lo scaffale esatto. Meno lavoro deve fare Dataverse per individuare
9:45
Speaker 3: un record, più velocemente vengono eseguite ogni vista, filtro e automazione.
9:49
Speaker 3: Dataverse crea automaticamente determinati indici per te, principalmente su chiavi primarie,
9:54
Speaker 3: ricerche e alcune colonne di sistema. Ecco perché i nuovi
9:57
Speaker 3: ambienti spesso funzionano bene, senza alcuna indicizzazione. manuale ma l'indicizzazione
10:01
Speaker 3: automatica ha dei limiti le query complesse con condizioni multiple
10:04
Speaker 3: specialmente su colonne personalizzate potrebbero finire per scansionare ampie parti
10:08
Speaker 3: della tabella perché non c'è un indice mirato a guidarle
10:11
Speaker 3: ah è a quel punto che inizia a vedere dashboard
10:13
Speaker 3: elente ritardi nei report e vista elenco che non si
10:16
Speaker 3: caricano in modo fluido L'altro estremo, l'eccessiva indicizzazione, può essere
10:19
Speaker 3: tanto dannoso. Ogni volta che inserisci, aggiorni o elimini un record,
10:23
Speaker 3: Dataverse deve mantenere tutti gli indici pertinenti. Troppi indici personalizzati
10:28
Speaker 3: possono aumentare i tempi di scrittura e rallentare gli aggiornamenti
10:31
Speaker 3: in blocco. L'arte qui sta nel sapere quali colonne vale
10:35
Speaker 3: la pena indicizzare e, altrettanto importante, quali non lo sono.
10:38
Speaker 3: Gli indici sono più preziosi sui campi usati frequentemente in filtri,
10:42
Speaker 3: ordinamenti o join, non su quelli che contano. Solo in
10:45
Speaker 3: occasionali viste di modulo, Ad esempio, su una tabella di
10:48
Speaker 3: richieste di servizio ad alto volume, i report impiegavano fino
10:50
Speaker 3: a 6 secondi, solo per istituire un elenco filtrato ai manager.
10:54
Speaker 3: Il problema principale era che il filtraggio avveniva su una
10:56
Speaker 3: colonna personalizzata del tipo di richiesta priva di un indice dedicato.
11:00
Speaker 3: L'aggiunta di un indice non clasterizzato su quella colonna ridotto
11:02
Speaker 3: immediatamente il tempo di esecuzione della query, a meno di
11:05
Speaker 3: 200 millisecondi. Non è un miglioramento da po'. Ha cambiato
11:08
Speaker 3: completamente la percezione dell'app per gli utenti quotidiani. E la
11:11
Speaker 3: parte migliore è che non ha richiesto di modificare il
11:12
Speaker 3: modello dati o la logica dell'interfaccia, solo un percorso di
11:15
Speaker 3: recupero più intelligente. ma ottenere quel vantaggio a posteriori non
11:18
Speaker 3: è l'ideale. L'aggiunta di indici in un sistema attivo comporta
11:22
Speaker 3: dei rischi. È necessario testare gli impatti sulla scrittura, pianificare
11:26
Speaker 3: le modifiche durante le finestre di basso utilizzo e talvolta
11:29
Speaker 3: gestire l'overhead di migrazione, se la tabella è molto grande.
11:33
Speaker 3: Al contrario, pianificare la strategia di indicizzazione prima del lancio
11:36
Speaker 3: rende l'intero sistema più resiliente. Puoi abbinare gli indici alle
11:39
Speaker 3: query più comuni fin da primo giorno, riducendo la necessità
11:41
Speaker 3: di correzioni urgenti delle prestazioni in seguito. Un buon approccio
11:45
Speaker 3: durante la pianificazione dello schema è mappare le query a
11:47
Speaker 3: traffico più elevato e identificare i campi su cui filtrano spesso.
11:51
Speaker 3: Si sa che una vista o una schermata dell'app ordinerà
11:53
Speaker 3: sempre per una determinata colonna. Considera di indicizzarla fin dall'inizio.
11:56
Speaker 3: Lo stesso vale per le condizioni di join e le
11:58
Speaker 3: relazioni che se essere centrali per il flusso di lavoro dell'app.
12:01
Speaker 3: Quindi rivedi periodicamente le statistiche di utilizzo degli indici per
12:04
Speaker 3: trovare quelli da eliminare perché raramente utilizzati nelle query reali.
12:08
Speaker 3: L'indicizzazione non è appariscente e non appare nell'interfaccia utente come
12:11
Speaker 3: un nuovo modulo o dashboard ma è un moltiplicatore reale
12:14
Speaker 3: silenzioso ogni query ottimizzata ne trae vantaggio e ogni query
12:18
Speaker 3: scarsamente indicizzata diventa un freno man mano che il set
12:20
Speaker 3: di dati cresce una strategia di indicizzazione efficace garantisce un
12:24
Speaker 3: margine di prestazioni e trasforma l'esecuzione delle query da un
12:26
Speaker 3: potenziale collo di bottiglie in un punto di forza affidabile
12:29
Speaker 3: ma c'è ancora un'altra leva da azionare per mantenere Dataverse
12:33
Speaker 3: davvero veloce su larga scala devi passare da risolvere i
12:36
Speaker 3: colli di bottiglia dopo la loro comparsa al progettare in
12:38
Speaker 3: modi che ne impediscono la formazione dalle correzioni reattive all'architettura
12:43
Speaker 3: proattiva La maggior parte delle correzioni di prestazioni in Dataverse
12:45
Speaker 3: sembra un lavoro di spegnimento in cieco. Un utente segnala
12:48
Speaker 3: moduli lenti, esegue alcuni controlli, apporti modifiche mirate e speri
12:51
Speaker 3: che il problema si risolva. Ma cosa succederebbe se potessi
12:53
Speaker 3: costruire in modo tale da impedire del tutto l'insorgere di
12:55
Speaker 3: tali problemi? La verità silenziosa è che le app Dataverse
12:59
Speaker 3: più veloci e stabili non sono solo ben ottimizzate, sono
13:02
Speaker 3: state progettate fin dal primo giorno pensando alla scalabilità. Una
13:05
Speaker 3: pianificazione architettonica precoce e un miglioramento delle prestazioni più economico
13:08
Speaker 3: che tu possa mai implementare. Non si tratta di aggiungere
13:11
Speaker 3: livelli extra in anticipo per sicurezza, ma di riflettere su
13:13
Speaker 3: come tabelle, relazioni e indici si comporteranno quando l'app sosterrà
13:17
Speaker 3: il piano carico di produzione. Nella fase di costruzione, modificare
13:22
Speaker 3: ogni decisione è un costo ridotto. Una volta che l'app
13:25
Speaker 3: è attiva, quella stessa modifica potrebbe richiedere refactoring di decine
13:27
Speaker 3: di flussi, dashboard e model driven. La differenza in termini
13:30
Speaker 3: di sforzo è enorme. Ho lavorato con team che non
13:32
Speaker 3: hanno effettuato test sulle prestazioni fino a poco prima del lancio.
13:36
Speaker 3: Tutto era stato costruito logicamente, appariva pulito nello schema e
13:38
Speaker 3: funzionava bene, nei test di accettazione. Ma poi, i report
13:42
Speaker 3: analitici hanno iniziato a richiedere minuti per caricarsi, i flussi
13:45
Speaker 3: di power automate andavano in timeout e alcuni moduli si
13:47
Speaker 3: aprivano solo a metà. In un caso, un'app di pianificazione
13:51
Speaker 3: centrale ha dovuto essere smantellata e ricostruita, perché diverse query
13:54
Speaker 3: chiave dipendevano da campi non indicizzati sepolti in join, molti
13:57
Speaker 3: a molti. La ricostruzione ha posticipato il lancio di tre
14:00
Speaker 3: mesi e ha bruciato settimane di lavoro di sviluppo e test.
14:05
Speaker 3: La chiave per evitare questo scenario è rendere le prestazioni
14:07
Speaker 3: un requisito di progettazione e non ripensamento. Ciò significa pianificare
14:11
Speaker 3: l'indicizzazione contemporaneamente alla progettazione delle tabelle, sapendo quali campi saranno
14:15
Speaker 3: ogni filtro e assicurandosi che siano pronti per ricerche efficienti.
14:19
Speaker 3: Significa resistere alla tentazione di aggiungere decine di campi per
14:21
Speaker 3: sicurezza durante la prototipazione, poiché ognuno aggiunge peso a moduli
14:25
Speaker 3: e transazioni. E significa modellare le relazioni in base a
14:28
Speaker 3: come si comporteranno su larga scala, non solo a quanto
14:31
Speaker 3: appaiono ordinate nei diagrammi di una sessione di lavoro, Quando
14:34
Speaker 3: tratti le prestazioni come parte dell'architettura dipendi molto meno dalla
14:37
Speaker 3: risoluzione dei problemi post distribuzione. Individui potenziali colli di bottiglia
14:41
Speaker 3: quando è ancora facile cambiare direzione. Se un certo modello
14:44
Speaker 3: di relazione rallentasse le join in set di dati di
14:46
Speaker 3: grandi dimensioni trovi una struttura alternativa prima che alimenti un
14:49
Speaker 3: sistema attivo. Se un indice potesse rendere istantanea una vista
14:52
Speaker 3: ad alto traffico lo aggiungi prima che la vista diventi fondamentale.
14:55
Speaker 3: È molto più facile che spiegare agli utenti aziendali perché
14:57
Speaker 3: l'app ora funziona diversamente solo perché hai dovuto riparare qualcosa
15:00
Speaker 3: che non sapevano fosse rotto Esistono strumenti nell'ecosistema Microsoft che
15:04
Speaker 3: rendono questo approccio proattivo molto più facile da applicare. Il
15:08
Speaker 3: controllo soluzioni analizzerà il tuo ambiente e indicherà i pattern
15:10
Speaker 3: che sa poter causare cari di prestazioni. L'analisi delle prestazioni
15:14
Speaker 3: nell'interfaccia di amministrazione di Power Platform possono aiutarti a individuare
15:17
Speaker 3: query lente, tracciare i tempi di caricamento dei moduli e
15:20
Speaker 3: identificare dove il recupero o il rendering subisce rallentamenti. Eseguire
15:23
Speaker 3: questi strumenti durante la costruzione e prima dei rilasci importanti,
15:26
Speaker 3: quanto di più vicino puoi ottenere un'assicurazione sulle prestazioni, sulle
15:28
Speaker 3: prestazioni e sulle prestazioni senza che gli utenti attivi dei test.
15:31
Speaker 3: Il vantaggio di lavorare in questo modo è semplice. Le
15:34
Speaker 3: app costruite con un pensiero proattivo alle prestazioni tendono a
15:36
Speaker 3: scalare senza problemi con modifiche minime. Quando il volume dei
15:40
Speaker 3: dati cresce non raggiungono improvvisamente i limiti inaspettati. Quando vengono
15:43
Speaker 3: aggiunte nuove funzionalità nulla si blocca perché il design originale
15:46
Speaker 3: ha lasciato spazio.