Dataverse-Standardtabellen vs. virtuelle Tabellen: Wann Sie das Kopieren von Daten beenden sollten

Von Mirko Peters · 2026-08-22

Vergleichen Sie Dataverse-Standardtabellen und virtuelle Tabellen. Erfahren Sie, wann Sie das Kopieren von Unternehmensdaten beenden sollten und wie Sie Live-Einblicke in externe Systeme umsetzen.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Die Entscheidung zwischen einer Dataverse-Standardtabelle und einer virtuellen Tabelle bestimmt, wie effizient Ihr Unternehmen mit externen Daten arbeitet. Standardtabellen speichern Datensätze direkt in Dataverse. Virtuelle Tabellen dagegen schaffen Live-Einblicke in externe ERP-, Lager- oder Finanzsysteme und machen riskante nächtliche Synchronisierungsjobs und veraltete Informationen überflüssig.

Das Wichtigste in Kürze

• Standard-Dataverse-Tabellen speichern Datensätze dauerhaft lokal. Virtuelle Tabellen zeigen dagegen Live-Datensätze an, die bei Bedarf aus externen Quellen abgerufen werden.
• Virtuelle Tabellen machen nächtliche Synchronisierungsjobs überflüssig, die Vertriebsteams mit veralteten Lagerbeständen konfrontieren würden.
• Architekturentscheidungen sollten sich daran orientieren, wo der Kerngeschäftsprozess und die Lebenszyklusverwaltung der Datensätze tatsächlich angesiedelt sind.
• Leistung, Sicherheitsberechtigungen und Filtermöglichkeiten verhalten sich bei virtuellen Tabellen aufgrund der Abhängigkeit von externen Daten anders.
• Unternehmen können Speicheraufwand und Datenduplizierung reduzieren, indem sie Benutzer direkt über Dynamics 365 mit den maßgeblichen externen Anwendungen verbinden.

Das Architekturdilemma: Speicher vs. Zugriff

Bei der Implementierung von Microsoft Dynamics 365 oder individuellen Power Apps stehen Architekten immer wieder vor einer grundlegenden Designfrage: Sollen wir externe Daten in Dataverse kopieren oder in ihrem ursprünglichen System belassen und eine Brücke bauen? Jahrelang war die Standardantwort die Replikation. Unternehmen planten nächtliche Integrationsroutinen, die Produktkataloge, Lagerbestände und Rechnungshistorien direkt in Dataverse übertrugen, damit Benutzer alles an einem Ort finden.

Diese Replikationsstrategie bringt jedoch erhebliche architektonische Lasten mit sich. Der Speicherbedarf wächst, die Datenbank bläht sich auf und vor allem entsteht durch veraltete Daten ein operatives Risiko. Wenn ein Lagermitarbeiter zur Mittagszeit zehn Einheiten eines kritischen Artikels versendet, zeigt eine replizierte Tabelle in Dataverse weiterhin diese zehn Einheiten an, bis der nächste geplante Batch-Sync läuft. Vertriebsmitarbeiter bieten dann nicht verfügbare Ware an, verärgerte Kunden stornieren Bestellungen und das Vertrauen leidet. Standardtabellen erfordern volle Verantwortung für die darin enthaltenen Daten und eignen sich daher schlecht für schnelllebige Betriebskennzahlen, die von spezialisierten Unternehmenssystemen verwaltet werden.

Standardtabellen und virtuelle Tabellen im Vergleich

Die operativen Unterschiede zwischen Dataverse-Standardtabellen und virtuellen Tabellen zu verstehen, hilft zu erkennen, wann welche Architektur sinnvoll ist. Der Unterschied geht weit über technische Feinheiten hinaus. Er bestimmt die Systemverantwortung, die Benutzerabläufe und den Wartungsaufwand.

Dataverse-Standardtabellen

Standardtabellen wie Konten, Kontakte und Opportunities sind native Bestandteile des Dataverse-Ökosystems. Dataverse erstellt die Datenbanktabellen, verwaltet den physischen Speicher, setzt tabellenbasierte Sicherheitsmodelle durch und führt Geschäftslogik, Plug-ins und Workflows direkt auf den Datensätzen aus. Wenn ein Benutzer einen Datensatz erstellt oder aktualisiert, ist Dataverse die maßgebliche Instanz. Anwendungsschicht und Speicherschicht sind vollständig vereinheitlicht.

Virtuelle Tabellen

Virtual Tables verhalten sich eher wie ein Bibliothekskatalog oder ein gesicherter Videostream. Dataverse speichert das Schema, die Spaltendefinitionen und die Metadaten, die für eine vertraute Benutzeroberfläche in modellgesteuerten Apps nötig sind, speichert die eigentlichen Datensätze jedoch nicht. Öffnet ein Benutzer eine Ansicht oder wendet er einen Filter an, übersetzt Dataverse die Anfrage, fragt das externe System über einen Datenprovider ab und zeigt die Live-Antwort sofort an. Die externe Anwendung bleibt die alleinige Instanz, die den Lebenszyklus der Datensätze bestimmt.

Betriebliche Kompromisse und Einschränkungen bewerten

Virtual Tables lösen zwar das Synchronisierungsproblem, bringen aber besondere Einschränkungen mit sich, die Entwickler und Administratoren sorgfältig prüfen sollten. Da die zugrunde liegenden Daten nicht in Dataverse liegen, verhalten sich bestimmte Plattformfunktionen anders als bei Standardtabellen.

Erweiterte Suche, komplexe serverseitige Plug-ins, Rollup-Felder und asynchrone Hintergrund-Workflows können sich unvorhersehbar verhalten oder vollständig fehlschlagen, wenn sie von lokal gespeicherten Daten ausgehen. Außerdem hängt die Leistung direkt vom Zustand und der Reaktionszeit der externen API oder Datenquelle ab. Hat die externe ERP- oder Lagerverwaltungsanwendung Latenzprobleme oder ist sie offline, bleiben die entsprechenden Virtual Tables in Dynamics 365 hängen oder zeigen Verbindungsfehler an.

Auch die Sicherheitsmodellierung erfordert sorgfältige Planung. Dataverse-Sicherheitsrollen können steuern, wer die Definition einer Virtual Table einsehen oder bearbeiten darf. Die zeilenbasierte Sicherheit muss jedoch häufig auf der Ebene der externen API oder über benutzerdefinierte Datenprovider durchgesetzt werden, damit Benutzer nur auf autorisierte Datensätze zugreifen.

Fazit

Ob Sie Standardtabellen in Dataverse oder Virtual Tables verwenden, hängt letztlich davon ab, wer den Lebenszyklus der Daten verantwortet und ob Ihre Benutzer eine dauerhafte lokale Speicherung oder nur eine kontextbezogene Sicht benötigen. Indem Sie externe Datenquellen abbilden, statt sie zu replizieren, können Unternehmen einen einheitlichen, übersichtlichen Arbeitsbereich in Dynamics 365 bewahren, ohne Dataverse zu einer unübersichtlichen Ablage für doppelte Datenbanktabellen zu machen. Um die grundlegenden Bausteine dieses Integrationsansatzes kennenzulernen, hören Sie sich die vollständige Episode an und abonnieren Sie den Podcast für weitere praxisnahe Cloud-Einblicke.

Häufige Fragen

Verbrauchen Virtual Tables Speicherkapazität in Dataverse?

Nein. Da Virtual Tables in Dataverse nur Tabellendefinitionen, Metadaten und Schemas speichern und die eigentlichen Datensätze im externen System belassen, belegen sie keine Speicherkapazität der Dataverse-Datenbank Ihrer Organisation.

Können Benutzer Datensätze bearbeiten, die über eine Virtual Table angezeigt werden?

Ja, sofern der zugrunde liegende Datenprovider und das externe System Schreibvorgänge unterstützen. Integrierte OData-v4-Provider und Finance-and-Operations-Integrationen unterstützen Erstellen-, Aktualisieren- und Löschen-Aktionen. Das externe System wendet jedoch weiterhin seine eigenen Validierungsregeln an.

Was passiert, wenn die externe Datenquelle offline ist?

Ist die externe Anwendung oder ihre API nicht verfügbar, erhalten Benutzer, die die Virtual Table in Dynamics 365 anzeigen, Ladefehler oder leere Tabellen, da die Echtzeitabfragen die externen Datensätze nicht abrufen können.

Sind Virtual Tables dasselbe wie Virtual Entities?

Ja. Virtual Entities ist der Begriff aus älterer Microsoft-Dokumentation und früheren Konfigurationen, während Virtual Tables die aktuelle offizielle Bezeichnung ist. Die zugrunde liegende Architektur und die Konzepte sind identisch.