WEBVTT 00:00:00.340 --> 00:00:06.840 Bereit für 10 Tage voller Microsoft 365 Co-Pilot, KI-Azure und den Vordenkern, die die Zukunft der Arbeit gestalten? 00:00:07.620 --> 00:00:11.580 Diesen Januar ist die M3 in 65 Jahren zurück und wir legen noch eine Schippe drauf. 00:00:11.760 --> 00:00:17.940 Wo drauf? Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenprofis aus aller Welt. 00:00:18.860 --> 00:00:21.320 Keine generischen Folien, kein endloses Buzzword-Bingo. 00:00:22.040 --> 00:00:27.840 Wir gehen die echten Herausforderungen an, Co-Pilot Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung. 00:00:27.840 --> 00:00:34.380 Egal ob IT-Profi, Entwickler oder Führungskraft, wir haben die passenden Sessions für Sie, wir Sie. 00:00:35.540 --> 00:00:39.940 An 10 vollen Tagen können Sie Technologien entdecken und sich mit einer globalen Community vernetzen. 00:00:40.920 --> 00:00:44.260 Schauen Sie live zu und nehmen Sie wertvolle Erkenntnisse mit in Ihr Unternehmen. 00:00:45.180 --> 00:00:50.640 Januar 2027, 10 Tage, eine Microsoft Community. Die Registrierung ist ab sofort geöffnet. 00:00:51.780 --> 00:00:55.620 Gehen Sie auf m3-65-con.net und sichern Sie sich noch heute Ihren Platz. 00:00:55.620 --> 00:00:58.360 Das ist m3-65-con.net. 00:01:00.100 --> 00:01:03.320 Melden Sie sich jetzt auf m3-65-con.net an. Wir sehen uns. 00:01:03.740 --> 00:01:04.580 Im Januar live. 00:01:05.280 --> 00:01:11.880 Was, wenn der Grund dafür, dass Ihre Dataverse-App extrem langsam wird, nicht die Datenmenge ist, sondern wie Ihre Beziehungen verknüpft sind? 00:01:13.440 --> 00:01:17.840 Heute analysieren wir den verborgenen Zusammenhang zwischen Schema-Design und tatsächlicher Reaktionszeit 00:01:17.840 --> 00:01:22.980 und warum viele Power-Plattform-Ersteller sich von Anfang an unwissentlich in eine schlechte Performance manövrieren. 00:01:25.150 --> 00:01:27.150 Die verborgenen Performance fallen in Ihren Tabellen. 00:01:28.010 --> 00:01:32.170 Haben Sie sich je gefragt, warum eine Tabelle mit nur wenigen tausend Zeilen langsamer wirkt als eine mit einer Million? 00:01:32.170 --> 00:01:38.730 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. 00:01:39.970 --> 00:01:45.490 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. 00:01:46.150 --> 00:01:51.230 Und diese Designentscheidungen verursachen Probleme, lange bevor Sie an die tatsächlichen Plattform-Limits stoßen. 00:01:52.190 --> 00:01:53.830 Viele Ersteller schieben die Schuld auf externe Faktoren. 00:01:54.250 --> 00:01:59.270 Sie vermuten, Ihr Tenant wird gedrosselt, das Netzwerk ist instabil oder es gibt einen versteckten Speichereinkpass im Dienst. 00:01:59.750 --> 00:02:00.150 Im Dienst. 00:02:01.350 --> 00:02:07.530 Doch oft lassen sich langsame Formulare, verzögerte Lookups und Power-Automate-Flows mit Timeouts auf ein Schema zurückführen, 00:02:07.530 --> 00:02:13.950 das in der Erstellungsphase perfekt aussah, aber so strukturiert war, dass jede darauf zugreifende Abfrage ausgebremst wird. 00:02:15.150 --> 00:02:19.450 Wenn sich ein Nutzer jemals über ein langsames Dataverse beschwert hat, ohne weitere Details zu nennen, 00:02:19.450 --> 00:02:22.210 liegt die Ursache sehr wahrscheinlich an Ihrem Tabellen-Layout. 00:02:23.090 --> 00:02:24.430 Stellen Sie es sich wie ein Aktenschrank vor. 00:02:25.290 --> 00:02:28.090 Wenn jede Schublade mit Papieren vollgestopft ist und nichts beschriftet ist, 00:02:28.350 --> 00:02:31.670 spielt es keine Rolle, ob nur 50 Dateien darin liegen, Sie verschwenden trotzdem Zeit mit der Suche. 00:02:33.050 --> 00:02:34.590 Eine Dataverse-Tabelle funktioniert genau gleich. 00:02:35.330 --> 00:02:38.270 Überladen mit selten genutzten Feldern und verknüpft durch unnötige Beziehungen 00:02:38.270 --> 00:02:40.830 kann Sie selbst einfache Datenvorgänge quälend langsam machen. 00:02:42.090 --> 00:02:45.950 Anders als bei einem unordentlichen Schrank ist das Chaos hier weder für Sie noch für den Benutzer sofort sichtbar. 00:02:46.790 --> 00:02:48.950 Das einzige Symptom ist ein zunehmender Leistungsverlust. 00:02:49.450 --> 00:02:53.090 Ich habe Projekte gesehen, bei denen das Tabellenschema wie eine Zusammenstellung aller Anforderungen, 00:02:53.250 --> 00:02:55.510 jedes Beteiligten wirkte, jedes Beteiligten wirkte. 00:02:55.650 --> 00:02:57.830 Ein Feld für interne Notizen in drei verschiedenen Formaten nötig. 00:02:58.250 --> 00:02:58.590 Erledigt. 00:02:58.910 --> 00:03:01.710 Ein Dutzend Varianten desselben Lookups, falls es später jemand braucht. 00:03:02.410 --> 00:03:03.010 Einfach hinzufügen. 00:03:03.310 --> 00:03:05.130 Mit der Zeit werden diese Felder zu unnötigen Ballast. 00:03:05.510 --> 00:03:08.830 Sie werden unnötig indiziert, verlangsamen Einfügungen und Aktualisierungen 00:03:08.830 --> 00:03:11.890 und machen die UI des Formulars schwerfälliger als nötig. 00:03:11.890 --> 00:03:16.190 Ein reales Beispiel betraf eine Kundentabelle mit über 250 Feldern, 00:03:16.270 --> 00:03:18.630 von denen die meisten nur für den Fall der Fälle existierten. 00:03:19.530 --> 00:03:23.690 Das Ergebnis, ein Formular, das bei einer Hochgeschwindigkeitsverbindung über zwölf Sekunden zum Laden brauchte. 00:03:24.310 --> 00:03:26.030 Und das war noch bevor jegliche Automatisierung griff. 00:03:26.410 --> 00:03:29.430 Die eigene Dokumentation von Microsoft erläutert die Kompromisse bei der Normalisierung. 00:03:30.330 --> 00:03:34.390 Nach Lehrbuch schützt die Aufteilung von Daten in viele kleine oder verknüpfte Tabellen vor Redundanz. 00:03:34.390 --> 00:03:38.630 In der Praxis kann eine Übernormalisierung die Dataverse-Leistung beeinträchtigen, 00:03:38.690 --> 00:03:41.410 wenn normale Vorgänge zu viele Joints über diese Tabellen erfordern. 00:03:42.790 --> 00:03:44.890 Jeder Join bedeutet zusätzliche Arbeit für die Abfrage-Engine. 00:03:46.170 --> 00:03:49.550 Und wenn Sie Spalten, die sich kaum ändern, in separaten, verknüpften Tabellen speichern, 00:03:49.690 --> 00:03:51.470 zahlen Sie einen Rechenaufwand ohne wirklichen Nutzen. 00:03:53.050 --> 00:03:56.150 Das Aussortieren unwichtiger Felder ist zwar keine glanzvolle Arbeit, zahlt sich aber schnell aus. 00:03:57.070 --> 00:03:59.110 Identifizieren Sie Attribute, die nicht für Berichte verwendet werden, 00:03:59.170 --> 00:04:01.150 sich selten ändern oder Informationen anderswo duplizieren. 00:04:01.150 --> 00:04:04.570 Behalten Sie nur das, was heute einen tatsächlichen Prozess unterstützt, 00:04:04.630 --> 00:04:05.970 nicht das, was eines Tages benötigt werden könnte. 00:04:06.330 --> 00:04:07.450 Dasselbe gilt für die Normalisierung. 00:04:07.890 --> 00:04:11.250 Es lohnt sich nun zu prüfen, wo Sie zusammengehörige, aber wenig genutzte Daten kombinieren können, 00:04:11.310 --> 00:04:12.030 um Joints zu reduzieren. 00:04:12.370 --> 00:04:14.590 Das Ziel ist nicht, gute Designprinzipien über Bord zu werfen, 00:04:14.670 --> 00:04:18.510 sondern Gleichgewicht zwischen Theorie und der tatsächlichen Ausführung Ihrer App unter Last zu finden. 00:04:19.250 --> 00:04:21.530 Die Realität ist, dass skalierbare Leistung nicht dadurch entsteht, 00:04:21.530 --> 00:04:23.450 dass man Dataverse einfach mehr Ressourcen zuweist. 00:04:24.050 --> 00:04:25.910 Es beginnt mit einem zweckmäßig entworfenen Schema. 00:04:26.590 --> 00:04:28.270 Schlanke Tabellen führen Befehle schneller aus, 00:04:28.630 --> 00:04:30.070 Formulare laden berechenbarer 00:04:30.070 --> 00:04:31.850 und Automatisierungen starten pünktlich, 00:04:31.970 --> 00:04:33.150 selbst wenn Ihre Umgebung wächst. 00:04:33.930 --> 00:04:37.570 Jedes unnötige Feld oder jede schlicht durchdachte Normalisierungsentscheidung 00:04:37.570 --> 00:04:38.530 erhöht den Widerstand. 00:04:38.970 --> 00:04:40.850 Bei jeder Abfrage, Abfrage. 00:04:41.570 --> 00:04:44.030 Mit der Zeit summiert sich dieser Widerstand seiner spürbaren Verzögerung. 00:04:44.510 --> 00:04:46.010 Nachdem der Faktor Unordnung nun offenlegt, 00:04:46.090 --> 00:04:46.870 verbirgt sich die nächste. 00:04:47.510 --> 00:04:49.270 Herausforderung in der Interaktion Ihrer Tabellen. 00:04:49.270 --> 00:04:53.010 Und genau da kann das Beziehungsdesign über Leistung oder Scheitern entscheiden. 00:04:55.110 --> 00:04:56.490 Wenn Beziehungen zu Hindernissen werden, 00:04:56.570 --> 00:04:59.690 gleichen manche Dataverse Beziehungen einer Kreuzung im Berufsverkehr A. 00:04:59.690 --> 00:05:01.450 Alles stört sich an einer Stelle 00:05:01.450 --> 00:05:03.510 und der gesamte Ablauf verlangsamt sich bis zum Stillstand. 00:05:04.330 --> 00:05:06.710 Auf dem Papier sieht die Datenstruktur sauber und logisch aus. 00:05:06.970 --> 00:05:09.910 Aber in der Praxis kann ein einziger überlasteter Verknüpfungspunkt 00:05:09.910 --> 00:05:12.030 eine gesamte modellgesteuerte App in die Knie zwingen. 00:05:13.030 --> 00:05:15.350 Es geht hier nicht um schlechte Daten oder riesige Volumina, 00:05:15.470 --> 00:05:17.730 sondern darum, wie die Beziehungen unter der Haube verknüpft sind. 00:05:18.730 --> 00:05:21.470 Das Beziehungsdesign kann unbemerkt Performance-Probleme verursachen, 00:05:21.550 --> 00:05:23.470 die erst bei realen Größenordnungen sichtbar werden. 00:05:24.010 --> 00:05:26.930 In kleineren Testumgebungen laufen selbstineffiziente Joints problemlos. 00:05:26.930 --> 00:05:29.970 Setzt man dasselbe Design in einer Unternehmensumgebung 00:05:29.970 --> 00:05:32.490 mit tausenden aktiven Nutzern und vernetzten Prozessen ein, 00:05:32.610 --> 00:05:33.970 laden Formulare plötzlich langsam, 00:05:34.310 --> 00:05:35.730 Subgrids laufen in Timeouts 00:05:35.730 --> 00:05:38.930 und alles, was diese verknüpften Tabellen betrifft, 00:05:39.130 --> 00:05:39.990 wirkt träge. 00:05:41.890 --> 00:05:43.790 Das sind keine mysteriösen Cloud-Verlangsamungen, 00:05:43.990 --> 00:05:45.810 sondern das natürliche Ergebnis von Beziehungen, 00:05:45.870 --> 00:05:47.150 die auf Klarheit ausgelegt sind, 00:05:47.230 --> 00:05:49.370 ohne zu berücksichtigen, wie Dataverse-Abfragen 00:05:49.370 --> 00:05:50.770 tatsächlich ausführt. 00:05:50.770 --> 00:05:53.450 Ich habe das selbst bei einem Projekt erlebt, 00:05:53.570 --> 00:05:55.370 bei dem eine M-zu-N-Beziehung genutzt wurde, 00:05:55.530 --> 00:05:57.730 um Kontakte mit mehreren Serviceplänen zu verknüpfen. 00:05:58.650 --> 00:06:00.950 In ersten Test mit ein paar hundert Datensätzen 00:06:00.950 --> 00:06:01.890 lief alles reibungslos. 00:06:03.470 --> 00:06:06.630 Doch als der Live-Datenbestand auf hunderttausende Anwuchs und Nutzer 00:06:06.630 --> 00:06:08.750 die Verknüpfungen täglich abfragten, 00:06:09.010 --> 00:06:12.830 wurde diese M-zu-N-Tabelle zum langsamsten Teil des Systems. 00:06:14.270 --> 00:06:17.310 Jeder Formularaufruf löste komplexe Joints über drei Tabellen aus, 00:06:17.310 --> 00:06:19.290 wobei jeder Join den Overhead erhöhte, 00:06:19.390 --> 00:06:21.810 bis grundlegende Vorgänge viel länger dauerten als erwartet. 00:06:22.670 --> 00:06:24.610 Die versteckten Kosten liegen nicht nur in den Joints selbst. 00:06:25.710 --> 00:06:28.450 Lookup-Felder in Dataverse können kaskadierende Verhaltensweisen 00:06:28.450 --> 00:06:31.250 wie automatische Neuzuweisungen, Löschungen oder Updates enthalten, 00:06:31.350 --> 00:06:33.830 die bei jeder Änderung am verknüpften Datensatz ausgeführt werden. 00:06:35.170 --> 00:06:37.570 Obwohl diese für die Datensynchronität großartig sind, 00:06:38.190 --> 00:06:40.470 bedeuten sie bei jedem Update auch mehr Hintergrundverarbeitung, 00:06:40.650 --> 00:06:43.270 selbst für Felder, die nichts mit dem Hauptvorgang zu tun haben. 00:06:43.650 --> 00:06:43.890 GR 00:06:43.890 --> 00:06:48.270 In Tabellen mit hoher Aktivität können sich diese Kaskaden schnell summieren, 00:06:48.410 --> 00:06:52.290 was den Durchsatz reduziert und Interaktionen ohne offensichtlichen Auslöser verlangsamt. 00:06:53.630 --> 00:06:56.010 Microsofts eigene Richtlinien raten aus gutem Grund dazu, 00:06:56.150 --> 00:06:57.710 unnötig komplexe Joints zu vermeiden. 00:06:58.950 --> 00:07:02.130 Jeder zusätzliche Join in einer Abfrage zwingt die Dataverse-Engine dazu, 00:07:02.230 --> 00:07:04.050 mehr Arbeit zu leisten, mehr Daten zu übersetzen 00:07:04.050 --> 00:07:06.330 und mehr Informationen im Arbeitsspeicher zu halten, 00:07:06.390 --> 00:07:07.830 während Bedingungen ausgewertet werden. 00:07:07.830 --> 00:07:10.370 In kleinen Dosen ist das handhabbar, 00:07:10.870 --> 00:07:15.410 doch sobald man mehrere M-N-Beziehungen und Kaskaden in denselben Prozess einbaut, 00:07:15.570 --> 00:07:18.610 steigt die Ausführungszeit viel schneller als erwartet. 00:07:18.930 --> 00:07:19.310 Shenzhen 00:07:19.310 --> 00:07:22.590 Ein besonders aufschlussreicher Fall betraf die Umstellung einer Beziehung 00:07:22.590 --> 00:07:25.870 von einer M-to-N-Beziehung auf ein einfaches Look-up mit einem unterstützenden Auswahlfeld. 00:07:27.070 --> 00:07:28.950 Die Geschäftslogik wurde leicht überarbeitet, 00:07:29.010 --> 00:07:32.990 sodass kein dynamisches Auflösen mehrerer verknüpfter Datensätze mehr nötig war, 00:07:32.990 --> 00:07:37.250 was zu einer sofortigen Reduzierung der Ladezeit um 80% führte. 00:07:38.630 --> 00:07:41.910 Diese Verbesserung lag nicht daran, dass der Datensatz schrumpfte oder die Hardware besser wurde. 00:07:42.790 --> 00:07:45.450 Es lag einzig daran, Dataverse einen einfachen und direkteren Weg 00:07:45.450 --> 00:07:47.530 zu den benötigten Informationen zu geben, zu geben. 00:07:48.230 --> 00:07:51.190 Alternative Designs wie das Vereinfachen von Strukturen können sich ebenfalls auszahlen. 00:07:52.090 --> 00:07:55.450 Manchmal muss ein Datenelement nicht in einer eigenen dedizierten Tabelle liegen. 00:07:56.950 --> 00:07:59.330 Wenn es wartungsarm ist und sich selten ändert, bedeutet das 00:07:59.590 --> 00:08:03.330 Speichern direkt im Hauptdatensatz als Auswahlfeld einen Join weniger beim Abrufen. 00:08:03.330 --> 00:08:09.420 Ähnlich können einige Verknüpfungstabellen durch berechnete oder Roll-up-Felder ersetzt werden, 00:08:09.500 --> 00:08:12.600 wenn sie hauptsächlich zur Anzeige zusammengefasster Informationen dienen. 00:08:13.620 --> 00:08:17.480 Dadurch bleibt die Darstellungsebene schnell und rechenintensive Abfragevorgänge im Hintergrund werden vermieden. 00:08:17.480 --> 00:08:22.280 Die Kernbotschaft lautet, beim Beziehungsdesign geht es nicht nur um logische Klarheit 00:08:22.280 --> 00:08:24.880 oder die Einhaltung von Normalisierung-Standards. 00:08:25.720 --> 00:08:27.660 Es geht auch darum, die Ausführungskosten zu verstehen. 00:08:28.420 --> 00:08:33.160 Jeder gewählte Beziehungstyp ändert, wie Dataverse ihre Daten abrufen, verknüpfen und verarbeiten muss. 00:08:33.540 --> 00:08:33.780 Muss? 00:08:35.180 --> 00:08:38.920 Wenn Sie sich nur auf das Aussehen des Schemas konzentrieren, ohne die Ausführung zu berücksichtigen. 00:08:38.980 --> 00:08:43.480 Halten Sie eine Struktur, die auf dem Papier perfekt ist, sich in der Produktion aber quälend langsam anfühlt. 00:08:43.480 --> 00:08:49.020 Und während die Optimierung von Beziehungen einen großen Teil dieses Verarbeitungsaufwands beseitigt, 00:08:49.120 --> 00:08:52.640 gibt es einen weiteren Faktor, der die Reaktionsgeschwindigkeit von Dataverse bestimmt, 00:08:52.880 --> 00:08:55.500 die Indizierungsstrategie, die diesen Abfragen zugrunde liegt. 00:08:57.240 --> 00:08:59.080 Indizierung der stille Leistungsbeschleuniger 00:08:59.080 --> 00:09:01.800 Abfragen sind nur so schnell wie die Pfade, die Sie nutzen können. 00:09:02.600 --> 00:09:04.500 Und in Dataverse bestimmt die Indizierung diesen Pfad. 00:09:05.460 --> 00:09:07.920 Die meisten Entwickler wissen zwar, dass Indizes existieren, 00:09:08.060 --> 00:09:11.780 doch in der Praxis ist dies einer der am wenigsten verstandenen Aspekte der Leistungsoptimierung. 00:09:11.780 --> 00:09:16.020 Sie können eine saubere Tabellenstruktur und optimierte Beziehungen haben. 00:09:16.700 --> 00:09:19.580 Aber wenn Dataverse die benötigten Datensätze nicht schnell findet, 00:09:19.760 --> 00:09:21.600 bremst die langsamste Suche alles andere aus. 00:09:22.340 --> 00:09:25.400 Stellen Sie es sich so vor, als würden Sie eine einzelne Kiste in einem riesigen Lagerhaus suchen. 00:09:26.540 --> 00:09:31.720 Ohne Indizierung laufen Sie Gang für Gang ab und prüfen jedes Regal, bis Sie das Richtige gefunden haben. 00:09:33.040 --> 00:09:34.540 Das funktioniert bei einem kleinen Lager, 00:09:34.640 --> 00:09:37.400 aber wenn Sie auf Millionen von Artikeln skalieren, wird es absurd. 00:09:37.800 --> 00:09:38.240 Ist absurd. 00:09:38.240 --> 00:09:42.380 Indizierung ist gleichbedeutend mit einer präzisen Karte und dem direkten Weg zum richtigen Regal. 00:09:43.320 --> 00:09:45.720 Je weniger Arbeit Dataverse hat, um einen Datensatz zu finden, 00:09:45.840 --> 00:09:48.340 desto schneller laufen alle Ansichten, Filter und Automatisierungen. 00:09:49.540 --> 00:09:51.880 Dataverse erstellt automatisch bestimmte Indizes für Sie. 00:09:53.180 --> 00:09:56.100 Hauptsächlich für Primärschlüsse, Suchfelder und einige Systemspalten. 00:09:56.100 --> 00:10:00.200 Deshalb funktionieren neue Umgebungen oft auch ohne manuelle Indizierung gut, 00:10:00.280 --> 00:10:02.120 aber die automatische Indizierung hat ihre Grenzen. 00:10:02.600 --> 00:10:06.060 Komplexe Abfragen mit mehreren Bedingungen, insbesondere bei benutzerdefinierten Spalten, 00:10:06.400 --> 00:10:08.860 können dazu führen, dass große Teile der Tabelle durchsucht werden, 00:10:09.140 --> 00:10:10.820 da kein gezielter Index vorhanden ist. 00:10:11.140 --> 00:10:15.640 An diesem Punkt bemerken Sie langsame Dashboards, verzögerte Berichte und Listenansichten, 00:10:15.780 --> 00:10:16.900 die nicht flüssig laden. 00:10:16.900 --> 00:10:20.500 Das andere Extrem, eine Überindizierung, kann genauso schlimm sein. 00:10:21.120 --> 00:10:24.080 Jedes Mal, wenn Sie einen Datensatz einfügen, aktualisieren oder löschen, 00:10:24.160 --> 00:10:26.160 muss Dataverse alle relevanten Indizes pflegen. 00:10:27.080 --> 00:10:29.740 Zu viele benutzerdefinierte Indizes können die Schreibzeiten erhöhen 00:10:29.740 --> 00:10:31.720 und Massenaktualisierungen verlangsamen. 00:10:33.100 --> 00:10:36.300 Die Kunst besteht darin zu wissen, welche Spalten einer Indizierung wert sind 00:10:36.300 --> 00:10:37.840 und ebenso wichtig, welche nicht. 00:10:38.840 --> 00:10:42.960 Indizes sind am wertvollsten für Felder, die häufig in Filtern, Sortierungen oder Verknüpfungen verwendet werden, 00:10:43.140 --> 00:10:46.300 nicht für Felder, die nur gelegentlich in Formularansichten wichtig sind. 00:10:46.900 --> 00:10:50.900 Bei einer hochfrequentierten Serviceanforderungstabelle beispielsweise dauerten Berichte bis zu 6 Sekunden, 00:10:51.020 --> 00:10:53.040 nur um eine gefilterte Liste für Manager bereitzustellen. 00:10:54.060 --> 00:10:58.020 Das Hauptproblem war, dass die Filterung auf einer benutzerdefinierten Anforderungstyp-Spalte 00:10:58.020 --> 00:10:59.700 ohne dedizierten Index erfolgte. 00:11:00.500 --> 00:11:02.720 Das Hinzufügen eines nicht gruppierten Index auf dieser Spalte 00:11:02.720 --> 00:11:05.460 reduzierte die Abfragezeit sofort auf unter 200 Millisekunden. 00:11:06.200 --> 00:11:07.320 Das ist keine geringfügige Verbesserung. 00:11:07.660 --> 00:11:10.340 Es veränderte das Gefühl der App für die täglichen Benutzer grundlegend. 00:11:10.860 --> 00:11:14.620 Und das Beste daran, es erforderte keine Änderung am eigentlichen Datenmodell oder der UI-Lubic, 00:11:14.620 --> 00:11:16.260 nur einen intelligenteren Abrufpfad. 00:11:16.900 --> 00:11:19.280 Doch diesen Vorteil erst im Nachhinein zu nutzen, ist nicht ideal. 00:11:20.020 --> 00:11:23.260 Das nachträgliche Hinzufügen von Indizes in einem Live-System birgt Risiken. 00:11:24.220 --> 00:11:27.900 Sie müssen Schreibauswirkungen testen, Änderungen während schwacher Nutzungszeiten planen 00:11:27.900 --> 00:11:31.560 und manchmal den Migrationsaufwand bewältigen, wenn die Tabelle extrem groß ist. 00:11:32.900 --> 00:11:35.740 Im Gegensatz dazu macht die Planung Ihrer Indexstrategie vor dem Live-Gang 00:11:35.740 --> 00:11:37.640 das gesamte System widerstandsfähiger. 00:11:38.280 --> 00:11:40.860 Sie können Indizes von Anfang an auf Ihre häufigsten Abfragen abstimmen 00:11:40.860 --> 00:11:43.820 und so die Notwendigkeit für spätere Notfallleistungsoptimierung reduzieren. 00:11:44.520 --> 00:11:46.360 Ein guter Ansatz während der Schemaplanung ist es, 00:11:46.400 --> 00:11:48.780 Ihre zugriffsstärksten Abfragen zu kartieren und zu identifizieren, 00:11:48.840 --> 00:11:50.100 nach welchen Feldern Sie häufig filtern. 00:11:50.920 --> 00:11:52.860 Wenn Sie wissen, dass eine Ansicht oder ein App-Bildschirm 00:11:52.860 --> 00:11:54.320 immer nach einer bestimmten Spalte sortiert, 00:11:54.440 --> 00:11:56.020 sollten Sie diese von Anfang an indizieren. 00:11:56.880 --> 00:11:58.260 Gleiches gilt für Join-Bedingungen und Beziehungen, 00:11:58.340 --> 00:12:00.420 von denen Sie wissen, dass Sie für den Workflow der App zentral sind. 00:12:00.420 --> 00:12:03.840 Überprüfen Sie dann regelmäßig die Index-Nutzungsstatistiken, 00:12:03.940 --> 00:12:05.400 um Kandidaten zu finden, die Sie löschen können, 00:12:05.460 --> 00:12:07.240 da sie in realen Abfragen selten verwendet werden. 00:12:08.640 --> 00:12:11.460 Indizierung ist nicht auffällig und erscheint nicht in der UI 00:12:11.460 --> 00:12:14.700 wie ein neues Formular oder Dashboard, aber sie ist ein stiller Multiplikator. 00:12:16.180 --> 00:12:18.060 Jede optimierte Abfrage profitiert davon 00:12:18.060 --> 00:12:21.180 und jede schlecht indizierte wird zur Bremse, wenn Ihr Datensatz wächst. 00:12:21.840 --> 00:12:24.300 Eine effektive Indexstrategie sichert Leistungsspielraum 00:12:24.300 --> 00:12:26.860 und verwandelt die Abfrageausführung von einem potenziellen Engpass 00:12:26.860 --> 00:12:28.180 in eine zuverlässige Stärke. 00:12:28.180 --> 00:12:31.160 Aber es gibt noch einen weiteren Hebel, den man betätigen kann. 00:12:31.580 --> 00:12:33.780 Um Dataverse bei Skalierung wirklich schnell zu halten, 00:12:34.180 --> 00:12:37.220 müssen Sie davon wegkommen, Engpässe erst nach Ihrem Auftreten zu beheben 00:12:37.220 --> 00:12:40.040 und stattdessen so designen, dass sie gar nicht erst entstehen. 00:12:41.220 --> 00:12:43.600 Von reaktiven Korrekturen hin zu proaktiver Architektur. 00:12:44.040 --> 00:12:46.180 Die meisten Leistungsanpassungen in Dataverse fühlen sich wie Brandbekämpfung. 00:12:47.140 --> 00:12:48.740 Ein Benutzer meldet langsame Formulare, 00:12:48.860 --> 00:12:49.940 sie führen einige Prüfungen durch, 00:12:50.120 --> 00:12:52.160 nehmen chirurgische Änderungen vor und hoffen, dass es sich bessert. 00:12:52.740 --> 00:12:54.360 Aber was wäre, wenn Sie so bauen könnten, 00:12:54.360 --> 00:12:56.360 dass diese Probleme gar nicht erst auftreten? 00:12:56.360 --> 00:12:59.840 Die stille Wahrheit ist, dass die schnellsten und stabilsten Dataverse-Apps 00:12:59.840 --> 00:13:00.880 nicht nur gut abgestimmt sind, 00:13:01.040 --> 00:13:04.520 nimmt, sie wurden vom ersten Tag an mit Blick auf Skalierbarkeit entwickelt. 00:13:05.340 --> 00:13:07.960 Frühzeitige architektonische Planung ist der günstigste Leistungsschub, 00:13:08.020 --> 00:13:09.160 den Sie jemals implementieren werden. 00:13:10.080 --> 00:13:12.960 Es geht nicht darum, vorsorglich zusätzliche Ebenen hinzuzufügen, 00:13:13.100 --> 00:13:14.160 sondern darüber nachzudenken, 00:13:14.240 --> 00:13:16.640 wie sich Ihre Tabellen, Beziehungen und Indizes verhalten, 00:13:16.800 --> 00:13:19.060 wenn die App unter voller Produktionslast steht. 00:13:19.060 --> 00:13:23.080 In der Entwicklungsphase sind Änderungen kostengünstig. 00:13:23.880 --> 00:13:26.780 Sobald die App live ist, erfordert dieselbe Änderung die Überarbeitung 00:13:26.780 --> 00:13:29.480 Dutzender Flows, Dashboards und Modellgestalterformulare. 00:13:30.000 --> 00:13:31.360 Der Unterschied im Aufwand ist gewaltig. 00:13:31.900 --> 00:13:32.760 Ich habe mit Teams gearbeitet, 00:13:32.880 --> 00:13:35.100 die erst kurz vor dem Go-Live-Leistungstest durchgeführt haben. 00:13:36.160 --> 00:13:37.420 Alles war logisch aufgebaut, 00:13:37.600 --> 00:13:40.760 sah im Schema sauber aus und funktionierte im URT einwandfrei. 00:13:41.720 --> 00:13:44.860 Doch dann luden Analyseberichte minutenlang Power-Automate-Flows, 00:13:44.860 --> 00:13:48.780 liefen ab und bestimmte Formulare öffneten sich nur sporadisch einiges. 00:13:49.760 --> 00:13:51.860 In einem Fall musste eine zentrale Planungs-App 00:13:51.860 --> 00:13:53.660 komplett zerlegt und neu aufgebaut werden, 00:13:54.000 --> 00:13:56.040 da wichtige Abfragen auf nicht indizierten Feldern 00:13:56.040 --> 00:13:57.840 in N-zu-M-Beziehungen basierten. 00:13:58.720 --> 00:14:01.320 Der Neuaufbau verschob den Go-Live um drei Monate 00:14:01.320 --> 00:14:03.500 und kostete wochenlang Entwickler- und Testzeit. 00:14:03.820 --> 00:14:04.180 Das ist Pö. 00:14:04.680 --> 00:14:06.540 Der Schlüssel zur Vermeidung dieses Szenarios 00:14:06.540 --> 00:14:08.380 ist Leistung als Designanforderung zu betrachten, 00:14:08.480 --> 00:14:10.300 nicht als nachträglichen Gedanken, nicht als nach. 00:14:11.300 --> 00:14:13.820 Das bedeutet, die Indizierung bereits beim Tabellendesign zu planen, 00:14:13.820 --> 00:14:15.580 die Filterfelder zu kennen und sicherzustellen, 00:14:15.680 --> 00:14:17.060 dass sie effizient durchsuchbar sind. 00:14:18.840 --> 00:14:20.420 Es bedeutet, der Versuchung zu widerstehen, 00:14:20.480 --> 00:14:23.100 beim Prototyping vorsichtshalber dutzende Felder hinzuzufügen, 00:14:23.380 --> 00:14:25.720 da jedes davon Formulare und Transaktionen belastet. 00:14:27.480 --> 00:14:29.240 Und es bedeutet, Beziehungen für Ihre Leistung 00:14:29.240 --> 00:14:30.420 bei Skalierung zu modellieren, 00:14:30.580 --> 00:14:33.020 nicht nur für eine saubere Darstellung im Workshop. 00:14:33.980 --> 00:14:35.860 Wenn Sie Leistung als Teil der Architektur begreifen, 00:14:36.000 --> 00:14:37.620 sind Sie deutlich weniger auf Federbehebung 00:14:37.620 --> 00:14:38.880 nach dem Deployment angewiesen. 00:14:39.820 --> 00:14:41.220 Sie erkennen potenzielle Engpässe, 00:14:41.300 --> 00:14:42.840 wenn ein Richtungswechsel noch einfacher ist. 00:14:42.840 --> 00:14:45.120 Wenn ein Beziehungsmodell Verknüpfungen 00:14:45.120 --> 00:14:46.740 in großen Datensätzen verlangsamen würde, 00:14:47.080 --> 00:14:48.420 finden Sie eine alternative Struktur, 00:14:48.540 --> 00:14:49.780 bevor Sie ein Live-System antreibt. 00:14:50.520 --> 00:14:52.760 Wenn ein Index eine stark frequentierte Ansicht beschleunigen kann, 00:14:52.840 --> 00:14:54.640 fügen Sie ihn hinzu, bevor die Ansicht geschäftskritisch wird. 00:14:55.300 --> 00:14:57.340 Das ist deutlich einfacher als Anwendern zu erklären, 00:14:57.800 --> 00:14:59.060 warum Ihre App anders funktioniert, 00:14:59.180 --> 00:15:00.380 nur weil Sie etwas reparieren mussten, 00:15:00.460 --> 00:15:01.520 von dem Sie nichts wussten. 00:15:02.700 --> 00:15:04.500 Es gibt Tools im Microsoft-Ökosystem, 00:15:04.620 --> 00:15:06.960 die diese proaktive Denkweise wesentlich erleichtern. 00:15:06.960 --> 00:15:09.500 Der Lösungschecker scannt Ihre Umgebung 00:15:09.500 --> 00:15:10.420 und weist auch Muster hin, 00:15:10.420 --> 00:15:12.420 die Leistungseinbußen verursachen könnten. 00:15:14.420 --> 00:15:16.140 Leistungseinblicke im Power-Plattform-Admin-Center 00:15:16.140 --> 00:15:17.640 helfen Ihnen, langsame Abfragen zu finden, 00:15:17.760 --> 00:15:18.820 Ladezeiten zu verfolgen 00:15:18.820 --> 00:15:22.380 und Verzögerungen bei Abruf oder Rendering zu identifizieren. 00:15:23.780 --> 00:15:25.400 Diese Tools während der Entwicklung 00:15:25.400 --> 00:15:26.580 und vor Releases zu nutzen, 00:15:26.740 --> 00:15:27.420 ist die beste Leistungsgarantie, 00:15:28.280 --> 00:15:29.880 ohne dass Live-Anwender zu testern werden. 00:15:29.880 --> 00:15:32.860 Die Belohnung für diese Arbeitsweise ist simpel. 00:15:34.040 --> 00:15:36.220 Apps, die mit Fokus auf proaktive Leistung gebaut wurden, 00:15:36.540 --> 00:15:38.560 skalieren meist reibungslos mit minimalen Anpassungen. 00:15:39.540 --> 00:15:40.500 Wenn das Datenvolumen weg, 00:15:40.560 --> 00:15:42.460 stoßen Sie nicht plötzlich auf unerwartete Grenzen. 00:15:43.100 --> 00:15:44.340 Wenn neue Funktionen hinzugefügt werden, 00:15:44.400 --> 00:15:45.140 kommt nichts zum Stillstand, 00:15:45.220 --> 00:15:47.100 weil das ursprüngliche Design den nötigen Spielraum ließ.