Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Dataverse-Performance: skalierbare Datenmodelle mit schlankem Schema, klugen Beziehungen und Indizes (KI-Synchronfassung)

Transcript

Dataverse-Performance: skalierbare Datenmodelle mit schlankem Schema, klugen Beziehungen und Indizes (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage voller Microsoft 365 Co-Pilot, KI-Azure und den Vordenkern, die die Zukunft der Arbeit gestalten?
• 0:07
  Diesen Januar ist die M3 in 65 Jahren zurück und wir legen noch eine Schippe drauf.
• 0:11
  Wo drauf? Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenprofis aus aller Welt.
• 0:18
  Keine generischen Folien, kein endloses Buzzword-Bingo.
• 0:22
  Wir gehen die echten Herausforderungen an, Co-Pilot Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung.
• 0:27
  Egal ob IT-Profi, Entwickler oder Führungskraft, wir haben die passenden Sessions für Sie, wir Sie.
• 0:35
  An 10 vollen Tagen können Sie Technologien entdecken und sich mit einer globalen Community vernetzen.
• 0:40
  Schauen Sie live zu und nehmen Sie wertvolle Erkenntnisse mit in Ihr Unternehmen.
• 0:45
  Januar 2027, 10 Tage, eine Microsoft Community. Die Registrierung ist ab sofort geöffnet.
• 0:51
  Gehen Sie auf m3-65-con.net und sichern Sie sich noch heute Ihren Platz.
• 0:55
  Das ist m3-65-con.net.
• 1:00
  Melden Sie sich jetzt auf m3-65-con.net an. Wir sehen uns.
• 1:03
  Im Januar live.
• 1:05
  Was, wenn der Grund dafür, dass Ihre Dataverse-App extrem langsam wird, nicht die Datenmenge ist, sondern wie Ihre Beziehungen verknüpft sind?
• 1:13
  Heute analysieren wir den verborgenen Zusammenhang zwischen Schema-Design und tatsächlicher Reaktionszeit
• 1:17
  und warum viele Power-Plattform-Ersteller sich von Anfang an unwissentlich in eine schlechte Performance manövrieren.
• 1:25
  Die verborgenen Performance fallen in Ihren Tabellen.
• 1:28
  Haben Sie sich je gefragt, warum eine Tabelle mit nur wenigen tausend Zeilen langsamer wirkt als eine mit einer Million?
• 1:32
  Es ist einer dieser Momente, in denen Ihr Gefühl sagt, es müsste flüssig laufen, aber Dataverse fühlt sich an, als würde es sich durch nassen Zement bewegen.
• 1:39
  Die überraschende Wahrheit ist, es ist nicht die reine Größe, die Ihre App ausbremst, sondern die Art und Weise, wie die Tabelle von Grund auf entworfen wurde.
• 1:46
  Und diese Designentscheidungen verursachen Probleme, lange bevor Sie an die tatsächlichen Plattform-Limits stoßen.
• 1:52
  Viele Ersteller schieben die Schuld auf externe Faktoren.
• 1:54
  Sie vermuten, Ihr Tenant wird gedrosselt, das Netzwerk ist instabil oder es gibt einen versteckten Speichereinkpass im Dienst.
• 1:59
  Im Dienst.
• 2:01
  Doch oft lassen sich langsame Formulare, verzögerte Lookups und Power-Automate-Flows mit Timeouts auf ein Schema zurückführen,
• 2:07
  das in der Erstellungsphase perfekt aussah, aber so strukturiert war, dass jede darauf zugreifende Abfrage ausgebremst wird.
• 2:15
  Wenn sich ein Nutzer jemals über ein langsames Dataverse beschwert hat, ohne weitere Details zu nennen,
• 2:19
  liegt die Ursache sehr wahrscheinlich an Ihrem Tabellen-Layout.
• 2:23
  Stellen Sie es sich wie ein Aktenschrank vor.
• 2:25
  Wenn jede Schublade mit Papieren vollgestopft ist und nichts beschriftet ist,
• 2:28
  spielt es keine Rolle, ob nur 50 Dateien darin liegen, Sie verschwenden trotzdem Zeit mit der Suche.
• 2:33
  Eine Dataverse-Tabelle funktioniert genau gleich.
• 2:35
  Überladen mit selten genutzten Feldern und verknüpft durch unnötige Beziehungen
• 2:38
  kann Sie selbst einfache Datenvorgänge quälend langsam machen.
• 2:42
  Anders als bei einem unordentlichen Schrank ist das Chaos hier weder für Sie noch für den Benutzer sofort sichtbar.
• 2:46
  Das einzige Symptom ist ein zunehmender Leistungsverlust.
• 2:49
  Ich habe Projekte gesehen, bei denen das Tabellenschema wie eine Zusammenstellung aller Anforderungen,
• 2:53
  jedes Beteiligten wirkte, jedes Beteiligten wirkte.
• 2:55
  Ein Feld für interne Notizen in drei verschiedenen Formaten nötig.
• 2:58
  Erledigt.
• 2:58
  Ein Dutzend Varianten desselben Lookups, falls es später jemand braucht.
• 3:02
  Einfach hinzufügen.
• 3:03
  Mit der Zeit werden diese Felder zu unnötigen Ballast.
• 3:05
  Sie werden unnötig indiziert, verlangsamen Einfügungen und Aktualisierungen
• 3:08
  und machen die UI des Formulars schwerfälliger als nötig.
• 3:11
  Ein reales Beispiel betraf eine Kundentabelle mit über 250 Feldern,
• 3:16
  von denen die meisten nur für den Fall der Fälle existierten.
• 3:19
  Das Ergebnis, ein Formular, das bei einer Hochgeschwindigkeitsverbindung über zwölf Sekunden zum Laden brauchte.
• 3:24
  Und das war noch bevor jegliche Automatisierung griff.
• 3:26
  Die eigene Dokumentation von Microsoft erläutert die Kompromisse bei der Normalisierung.
• 3:30
  Nach Lehrbuch schützt die Aufteilung von Daten in viele kleine oder verknüpfte Tabellen vor Redundanz.
• 3:34
  In der Praxis kann eine Übernormalisierung die Dataverse-Leistung beeinträchtigen,
• 3:38
  wenn normale Vorgänge zu viele Joints über diese Tabellen erfordern.
• 3:42
  Jeder Join bedeutet zusätzliche Arbeit für die Abfrage-Engine.
• 3:46
  Und wenn Sie Spalten, die sich kaum ändern, in separaten, verknüpften Tabellen speichern,
• 3:49
  zahlen Sie einen Rechenaufwand ohne wirklichen Nutzen.
• 3:53
  Das Aussortieren unwichtiger Felder ist zwar keine glanzvolle Arbeit, zahlt sich aber schnell aus.
• 3:57
  Identifizieren Sie Attribute, die nicht für Berichte verwendet werden,
• 3:59
  sich selten ändern oder Informationen anderswo duplizieren.
• 4:01
  Behalten Sie nur das, was heute einen tatsächlichen Prozess unterstützt,
• 4:04
  nicht das, was eines Tages benötigt werden könnte.
• 4:06
  Dasselbe gilt für die Normalisierung.
• 4:07
  Es lohnt sich nun zu prüfen, wo Sie zusammengehörige, aber wenig genutzte Daten kombinieren können,
• 4:11
  um Joints zu reduzieren.
• 4:12
  Das Ziel ist nicht, gute Designprinzipien über Bord zu werfen,
• 4:14
  sondern Gleichgewicht zwischen Theorie und der tatsächlichen Ausführung Ihrer App unter Last zu finden.
• 4:19
  Die Realität ist, dass skalierbare Leistung nicht dadurch entsteht,
• 4:21
  dass man Dataverse einfach mehr Ressourcen zuweist.
• 4:24
  Es beginnt mit einem zweckmäßig entworfenen Schema.
• 4:26
  Schlanke Tabellen führen Befehle schneller aus,
• 4:28
  Formulare laden berechenbarer
• 4:30
  und Automatisierungen starten pünktlich,
• 4:31
  selbst wenn Ihre Umgebung wächst.
• 4:33
  Jedes unnötige Feld oder jede schlicht durchdachte Normalisierungsentscheidung
• 4:37
  erhöht den Widerstand.
• 4:38
  Bei jeder Abfrage, Abfrage.
• 4:41
  Mit der Zeit summiert sich dieser Widerstand seiner spürbaren Verzögerung.
• 4:44
  Nachdem der Faktor Unordnung nun offenlegt,
• 4:46
  verbirgt sich die nächste.
• 4:47
  Herausforderung in der Interaktion Ihrer Tabellen.
• 4:49
  Und genau da kann das Beziehungsdesign über Leistung oder Scheitern entscheiden.
• 4:55
  Wenn Beziehungen zu Hindernissen werden,
• 4:56
  gleichen manche Dataverse Beziehungen einer Kreuzung im Berufsverkehr A.
• 4:59
  Alles stört sich an einer Stelle
• 5:01
  und der gesamte Ablauf verlangsamt sich bis zum Stillstand.
• 5:04
  Auf dem Papier sieht die Datenstruktur sauber und logisch aus.
• 5:06
  Aber in der Praxis kann ein einziger überlasteter Verknüpfungspunkt
• 5:09
  eine gesamte modellgesteuerte App in die Knie zwingen.
• 5:13
  Es geht hier nicht um schlechte Daten oder riesige Volumina,
• 5:15
  sondern darum, wie die Beziehungen unter der Haube verknüpft sind.
• 5:18
  Das Beziehungsdesign kann unbemerkt Performance-Probleme verursachen,
• 5:21
  die erst bei realen Größenordnungen sichtbar werden.
• 5:24
  In kleineren Testumgebungen laufen selbstineffiziente Joints problemlos.
• 5:26
  Setzt man dasselbe Design in einer Unternehmensumgebung
• 5:29
  mit tausenden aktiven Nutzern und vernetzten Prozessen ein,
• 5:32
  laden Formulare plötzlich langsam,
• 5:34
  Subgrids laufen in Timeouts
• 5:35
  und alles, was diese verknüpften Tabellen betrifft,
• 5:39
  wirkt träge.
• 5:41
  Das sind keine mysteriösen Cloud-Verlangsamungen,
• 5:43
  sondern das natürliche Ergebnis von Beziehungen,
• 5:45
  die auf Klarheit ausgelegt sind,
• 5:47
  ohne zu berücksichtigen, wie Dataverse-Abfragen
• 5:49
  tatsächlich ausführt.
• 5:50
  Ich habe das selbst bei einem Projekt erlebt,
• 5:53
  bei dem eine M-zu-N-Beziehung genutzt wurde,
• 5:55
  um Kontakte mit mehreren Serviceplänen zu verknüpfen.
• 5:58
  In ersten Test mit ein paar hundert Datensätzen
• 6:00
  lief alles reibungslos.
• 6:03
  Doch als der Live-Datenbestand auf hunderttausende Anwuchs und Nutzer
• 6:06
  die Verknüpfungen täglich abfragten,
• 6:09
  wurde diese M-zu-N-Tabelle zum langsamsten Teil des Systems.
• 6:14
  Jeder Formularaufruf löste komplexe Joints über drei Tabellen aus,
• 6:17
  wobei jeder Join den Overhead erhöhte,
• 6:19
  bis grundlegende Vorgänge viel länger dauerten als erwartet.
• 6:22
  Die versteckten Kosten liegen nicht nur in den Joints selbst.
• 6:25
  Lookup-Felder in Dataverse können kaskadierende Verhaltensweisen
• 6:28
  wie automatische Neuzuweisungen, Löschungen oder Updates enthalten,
• 6:31
  die bei jeder Änderung am verknüpften Datensatz ausgeführt werden.
• 6:35
  Obwohl diese für die Datensynchronität großartig sind,
• 6:38
  bedeuten sie bei jedem Update auch mehr Hintergrundverarbeitung,
• 6:40
  selbst für Felder, die nichts mit dem Hauptvorgang zu tun haben.
• 6:43
  GR
• 6:43
  In Tabellen mit hoher Aktivität können sich diese Kaskaden schnell summieren,
• 6:48
  was den Durchsatz reduziert und Interaktionen ohne offensichtlichen Auslöser verlangsamt.
• 6:53
  Microsofts eigene Richtlinien raten aus gutem Grund dazu,
• 6:56
  unnötig komplexe Joints zu vermeiden.
• 6:58
  Jeder zusätzliche Join in einer Abfrage zwingt die Dataverse-Engine dazu,
• 7:02
  mehr Arbeit zu leisten, mehr Daten zu übersetzen
• 7:04
  und mehr Informationen im Arbeitsspeicher zu halten,
• 7:06
  während Bedingungen ausgewertet werden.
• 7:07
  In kleinen Dosen ist das handhabbar,
• 7:10
  doch sobald man mehrere M-N-Beziehungen und Kaskaden in denselben Prozess einbaut,
• 7:15
  steigt die Ausführungszeit viel schneller als erwartet.
• 7:18
  Shenzhen
• 7:19
  Ein besonders aufschlussreicher Fall betraf die Umstellung einer Beziehung
• 7:22
  von einer M-to-N-Beziehung auf ein einfaches Look-up mit einem unterstützenden Auswahlfeld.
• 7:27
  Die Geschäftslogik wurde leicht überarbeitet,
• 7:29
  sodass kein dynamisches Auflösen mehrerer verknüpfter Datensätze mehr nötig war,
• 7:32
  was zu einer sofortigen Reduzierung der Ladezeit um 80% führte.
• 7:38
  Diese Verbesserung lag nicht daran, dass der Datensatz schrumpfte oder die Hardware besser wurde.
• 7:42
  Es lag einzig daran, Dataverse einen einfachen und direkteren Weg
• 7:45
  zu den benötigten Informationen zu geben, zu geben.
• 7:48
  Alternative Designs wie das Vereinfachen von Strukturen können sich ebenfalls auszahlen.
• 7:52
  Manchmal muss ein Datenelement nicht in einer eigenen dedizierten Tabelle liegen.
• 7:56
  Wenn es wartungsarm ist und sich selten ändert, bedeutet das
• 7:59
  Speichern direkt im Hauptdatensatz als Auswahlfeld einen Join weniger beim Abrufen.
• 8:03
  Ähnlich können einige Verknüpfungstabellen durch berechnete oder Roll-up-Felder ersetzt werden,
• 8:09
  wenn sie hauptsächlich zur Anzeige zusammengefasster Informationen dienen.
• 8:13
  Dadurch bleibt die Darstellungsebene schnell und rechenintensive Abfragevorgänge im Hintergrund werden vermieden.
• 8:17
  Die Kernbotschaft lautet, beim Beziehungsdesign geht es nicht nur um logische Klarheit
• 8:22
  oder die Einhaltung von Normalisierung-Standards.
• 8:25
  Es geht auch darum, die Ausführungskosten zu verstehen.
• 8:28
  Jeder gewählte Beziehungstyp ändert, wie Dataverse ihre Daten abrufen, verknüpfen und verarbeiten muss.
• 8:33
  Muss?
• 8:35
  Wenn Sie sich nur auf das Aussehen des Schemas konzentrieren, ohne die Ausführung zu berücksichtigen.
• 8:38
  Halten Sie eine Struktur, die auf dem Papier perfekt ist, sich in der Produktion aber quälend langsam anfühlt.
• 8:43
  Und während die Optimierung von Beziehungen einen großen Teil dieses Verarbeitungsaufwands beseitigt,
• 8:49
  gibt es einen weiteren Faktor, der die Reaktionsgeschwindigkeit von Dataverse bestimmt,
• 8:52
  die Indizierungsstrategie, die diesen Abfragen zugrunde liegt.
• 8:57
  Indizierung der stille Leistungsbeschleuniger
• 8:59
  Abfragen sind nur so schnell wie die Pfade, die Sie nutzen können.
• 9:02
  Und in Dataverse bestimmt die Indizierung diesen Pfad.
• 9:05
  Die meisten Entwickler wissen zwar, dass Indizes existieren,
• 9:08
  doch in der Praxis ist dies einer der am wenigsten verstandenen Aspekte der Leistungsoptimierung.
• 9:11
  Sie können eine saubere Tabellenstruktur und optimierte Beziehungen haben.
• 9:16
  Aber wenn Dataverse die benötigten Datensätze nicht schnell findet,
• 9:19
  bremst die langsamste Suche alles andere aus.
• 9:22
  Stellen Sie es sich so vor, als würden Sie eine einzelne Kiste in einem riesigen Lagerhaus suchen.
• 9:26
  Ohne Indizierung laufen Sie Gang für Gang ab und prüfen jedes Regal, bis Sie das Richtige gefunden haben.
• 9:33
  Das funktioniert bei einem kleinen Lager,
• 9:34
  aber wenn Sie auf Millionen von Artikeln skalieren, wird es absurd.
• 9:37
  Ist absurd.
• 9:38
  Indizierung ist gleichbedeutend mit einer präzisen Karte und dem direkten Weg zum richtigen Regal.
• 9:43
  Je weniger Arbeit Dataverse hat, um einen Datensatz zu finden,
• 9:45
  desto schneller laufen alle Ansichten, Filter und Automatisierungen.
• 9:49
  Dataverse erstellt automatisch bestimmte Indizes für Sie.
• 9:53
  Hauptsächlich für Primärschlüsse, Suchfelder und einige Systemspalten.
• 9:56
  Deshalb funktionieren neue Umgebungen oft auch ohne manuelle Indizierung gut,
• 10:00
  aber die automatische Indizierung hat ihre Grenzen.
• 10:02
  Komplexe Abfragen mit mehreren Bedingungen, insbesondere bei benutzerdefinierten Spalten,
• 10:06
  können dazu führen, dass große Teile der Tabelle durchsucht werden,
• 10:09
  da kein gezielter Index vorhanden ist.
• 10:11
  An diesem Punkt bemerken Sie langsame Dashboards, verzögerte Berichte und Listenansichten,
• 10:15
  die nicht flüssig laden.
• 10:16
  Das andere Extrem, eine Überindizierung, kann genauso schlimm sein.
• 10:21
  Jedes Mal, wenn Sie einen Datensatz einfügen, aktualisieren oder löschen,
• 10:24
  muss Dataverse alle relevanten Indizes pflegen.
• 10:27
  Zu viele benutzerdefinierte Indizes können die Schreibzeiten erhöhen
• 10:29
  und Massenaktualisierungen verlangsamen.
• 10:33
  Die Kunst besteht darin zu wissen, welche Spalten einer Indizierung wert sind
• 10:36
  und ebenso wichtig, welche nicht.
• 10:38
  Indizes sind am wertvollsten für Felder, die häufig in Filtern, Sortierungen oder Verknüpfungen verwendet werden,
• 10:43
  nicht für Felder, die nur gelegentlich in Formularansichten wichtig sind.
• 10:46
  Bei einer hochfrequentierten Serviceanforderungstabelle beispielsweise dauerten Berichte bis zu 6 Sekunden,
• 10:51
  nur um eine gefilterte Liste für Manager bereitzustellen.
• 10:54
  Das Hauptproblem war, dass die Filterung auf einer benutzerdefinierten Anforderungstyp-Spalte
• 10:58
  ohne dedizierten Index erfolgte.
• 11:00
  Das Hinzufügen eines nicht gruppierten Index auf dieser Spalte
• 11:02
  reduzierte die Abfragezeit sofort auf unter 200 Millisekunden.
• 11:06
  Das ist keine geringfügige Verbesserung.
• 11:07
  Es veränderte das Gefühl der App für die täglichen Benutzer grundlegend.
• 11:10
  Und das Beste daran, es erforderte keine Änderung am eigentlichen Datenmodell oder der UI-Lubic,
• 11:14
  nur einen intelligenteren Abrufpfad.
• 11:16
  Doch diesen Vorteil erst im Nachhinein zu nutzen, ist nicht ideal.
• 11:20
  Das nachträgliche Hinzufügen von Indizes in einem Live-System birgt Risiken.
• 11:24
  Sie müssen Schreibauswirkungen testen, Änderungen während schwacher Nutzungszeiten planen
• 11:27
  und manchmal den Migrationsaufwand bewältigen, wenn die Tabelle extrem groß ist.
• 11:32
  Im Gegensatz dazu macht die Planung Ihrer Indexstrategie vor dem Live-Gang
• 11:35
  das gesamte System widerstandsfähiger.
• 11:38
  Sie können Indizes von Anfang an auf Ihre häufigsten Abfragen abstimmen
• 11:40
  und so die Notwendigkeit für spätere Notfallleistungsoptimierung reduzieren.
• 11:44
  Ein guter Ansatz während der Schemaplanung ist es,
• 11:46
  Ihre zugriffsstärksten Abfragen zu kartieren und zu identifizieren,
• 11:48
  nach welchen Feldern Sie häufig filtern.
• 11:50
  Wenn Sie wissen, dass eine Ansicht oder ein App-Bildschirm
• 11:52
  immer nach einer bestimmten Spalte sortiert,
• 11:54
  sollten Sie diese von Anfang an indizieren.
• 11:56
  Gleiches gilt für Join-Bedingungen und Beziehungen,
• 11:58
  von denen Sie wissen, dass Sie für den Workflow der App zentral sind.
• 12:00
  Überprüfen Sie dann regelmäßig die Index-Nutzungsstatistiken,
• 12:03
  um Kandidaten zu finden, die Sie löschen können,
• 12:05
  da sie in realen Abfragen selten verwendet werden.
• 12:08
  Indizierung ist nicht auffällig und erscheint nicht in der UI
• 12:11
  wie ein neues Formular oder Dashboard, aber sie ist ein stiller Multiplikator.
• 12:16
  Jede optimierte Abfrage profitiert davon
• 12:18
  und jede schlecht indizierte wird zur Bremse, wenn Ihr Datensatz wächst.
• 12:21
  Eine effektive Indexstrategie sichert Leistungsspielraum
• 12:24
  und verwandelt die Abfrageausführung von einem potenziellen Engpass
• 12:26
  in eine zuverlässige Stärke.
• 12:28
  Aber es gibt noch einen weiteren Hebel, den man betätigen kann.
• 12:31
  Um Dataverse bei Skalierung wirklich schnell zu halten,
• 12:34
  müssen Sie davon wegkommen, Engpässe erst nach Ihrem Auftreten zu beheben
• 12:37
  und stattdessen so designen, dass sie gar nicht erst entstehen.
• 12:41
  Von reaktiven Korrekturen hin zu proaktiver Architektur.
• 12:44
  Die meisten Leistungsanpassungen in Dataverse fühlen sich wie Brandbekämpfung.
• 12:47
  Ein Benutzer meldet langsame Formulare,
• 12:48
  sie führen einige Prüfungen durch,
• 12:50
  nehmen chirurgische Änderungen vor und hoffen, dass es sich bessert.
• 12:52
  Aber was wäre, wenn Sie so bauen könnten,
• 12:54
  dass diese Probleme gar nicht erst auftreten?
• 12:56
  Die stille Wahrheit ist, dass die schnellsten und stabilsten Dataverse-Apps
• 12:59
  nicht nur gut abgestimmt sind,
• 13:01
  nimmt, sie wurden vom ersten Tag an mit Blick auf Skalierbarkeit entwickelt.
• 13:05
  Frühzeitige architektonische Planung ist der günstigste Leistungsschub,
• 13:08
  den Sie jemals implementieren werden.
• 13:10
  Es geht nicht darum, vorsorglich zusätzliche Ebenen hinzuzufügen,
• 13:13
  sondern darüber nachzudenken,
• 13:14
  wie sich Ihre Tabellen, Beziehungen und Indizes verhalten,
• 13:16
  wenn die App unter voller Produktionslast steht.
• 13:19
  In der Entwicklungsphase sind Änderungen kostengünstig.
• 13:23
  Sobald die App live ist, erfordert dieselbe Änderung die Überarbeitung
• 13:26
  Dutzender Flows, Dashboards und Modellgestalterformulare.
• 13:30
  Der Unterschied im Aufwand ist gewaltig.
• 13:31
  Ich habe mit Teams gearbeitet,
• 13:32
  die erst kurz vor dem Go-Live-Leistungstest durchgeführt haben.
• 13:36
  Alles war logisch aufgebaut,
• 13:37
  sah im Schema sauber aus und funktionierte im URT einwandfrei.
• 13:41
  Doch dann luden Analyseberichte minutenlang Power-Automate-Flows,
• 13:44
  liefen ab und bestimmte Formulare öffneten sich nur sporadisch einiges.
• 13:49
  In einem Fall musste eine zentrale Planungs-App
• 13:51
  komplett zerlegt und neu aufgebaut werden,
• 13:54
  da wichtige Abfragen auf nicht indizierten Feldern
• 13:56
  in N-zu-M-Beziehungen basierten.
• 13:58
  Der Neuaufbau verschob den Go-Live um drei Monate
• 14:01
  und kostete wochenlang Entwickler- und Testzeit.
• 14:03
  Das ist Pö.
• 14:04
  Der Schlüssel zur Vermeidung dieses Szenarios
• 14:06
  ist Leistung als Designanforderung zu betrachten,
• 14:08
  nicht als nachträglichen Gedanken, nicht als nach.
• 14:11
  Das bedeutet, die Indizierung bereits beim Tabellendesign zu planen,
• 14:13
  die Filterfelder zu kennen und sicherzustellen,
• 14:15
  dass sie effizient durchsuchbar sind.
• 14:18
  Es bedeutet, der Versuchung zu widerstehen,
• 14:20
  beim Prototyping vorsichtshalber dutzende Felder hinzuzufügen,
• 14:23
  da jedes davon Formulare und Transaktionen belastet.
• 14:27
  Und es bedeutet, Beziehungen für Ihre Leistung
• 14:29
  bei Skalierung zu modellieren,
• 14:30
  nicht nur für eine saubere Darstellung im Workshop.
• 14:33
  Wenn Sie Leistung als Teil der Architektur begreifen,
• 14:36
  sind Sie deutlich weniger auf Federbehebung
• 14:37
  nach dem Deployment angewiesen.
• 14:39
  Sie erkennen potenzielle Engpässe,
• 14:41
  wenn ein Richtungswechsel noch einfacher ist.
• 14:42
  Wenn ein Beziehungsmodell Verknüpfungen
• 14:45
  in großen Datensätzen verlangsamen würde,
• 14:47
  finden Sie eine alternative Struktur,
• 14:48
  bevor Sie ein Live-System antreibt.
• 14:50
  Wenn ein Index eine stark frequentierte Ansicht beschleunigen kann,
• 14:52
  fügen Sie ihn hinzu, bevor die Ansicht geschäftskritisch wird.
• 14:55
  Das ist deutlich einfacher als Anwendern zu erklären,
• 14:57
  warum Ihre App anders funktioniert,
• 14:59
  nur weil Sie etwas reparieren mussten,
• 15:00
  von dem Sie nichts wussten.
• 15:02
  Es gibt Tools im Microsoft-Ökosystem,
• 15:04
  die diese proaktive Denkweise wesentlich erleichtern.
• 15:06
  Der Lösungschecker scannt Ihre Umgebung
• 15:09
  und weist auch Muster hin,
• 15:10
  die Leistungseinbußen verursachen könnten.
• 15:14
  Leistungseinblicke im Power-Plattform-Admin-Center
• 15:16
  helfen Ihnen, langsame Abfragen zu finden,
• 15:17
  Ladezeiten zu verfolgen
• 15:18
  und Verzögerungen bei Abruf oder Rendering zu identifizieren.
• 15:23
  Diese Tools während der Entwicklung
• 15:25
  und vor Releases zu nutzen,
• 15:26
  ist die beste Leistungsgarantie,
• 15:28
  ohne dass Live-Anwender zu testern werden.
• 15:29
  Die Belohnung für diese Arbeitsweise ist simpel.
• 15:34
  Apps, die mit Fokus auf proaktive Leistung gebaut wurden,
• 15:36
  skalieren meist reibungslos mit minimalen Anpassungen.
• 15:39
  Wenn das Datenvolumen weg,
• 15:40
  stoßen Sie nicht plötzlich auf unerwartete Grenzen.
• 15:43
  Wenn neue Funktionen hinzugefügt werden,
• 15:44
  kommt nichts zum Stillstand,
• 15:45
  weil das ursprüngliche Design den nötigen Spielraum ließ.