Tabelle standard di Dataverse vs tabelle virtuali: quando smettere di copiare i dati

By Mirko Peters · 2026-08-22

Confronta le tabelle standard e le tabelle virtuali di Dataverse. Scopri quando smettere di copiare i dati aziendali e come implementare finestre in tempo reale sui sistemi esterni.

Automatically translated with AI from the original post. Read the English original

Scegliere tra una tabella standard di Dataverse e una tabella virtuale determina l'efficienza con cui la tua azienda gestisce i dati esterni. Mentre le tabelle standard memorizzano i record direttamente in Dataverse, le tabelle virtuali creano finestre in tempo reale sui sistemi ERP, di magazzino o finanziari esterni, eliminando rischiosi job di sincronizzazione notturni e informazioni obsolete.

Punti chiave

• Le tabelle standard di Dataverse memorizzano i record in modo permanente in locale, mentre le tabelle virtuali mostrano record in tempo reale recuperati su richiesta dalle origini esterne.
• Usare le tabelle virtuali elimina la necessità di job di sincronizzazione notturni che espongono i team di vendita al rischio di giacenze non aggiornate.
• Le scelte architetturali dovrebbero dare priorità a dove risiedono davvero il processo aziendale principale e la gestione del ciclo di vita dei record.
• Prestazioni, autorizzazioni di sicurezza e funzionalità di filtro funzionano in modo diverso sulle tabelle virtuali a causa delle dipendenze dai dati esterni.
• Le organizzazioni possono ridurre il sovraccarico di archiviazione e la duplicazione dei dati collegando direttamente gli utenti alle applicazioni esterne autorevoli tramite Dynamics 365.

Il dilemma architetturale: archiviazione vs accesso

Quando si implementano Microsoft Dynamics 365 o app personalizzate con Power Apps, gli architetti si trovano continuamente di fronte a una domanda di progettazione fondamentale: dobbiamo copiare i dati esterni in Dataverse oppure lasciarli nel sistema di origine e costruire un ponte? Per anni la risposta predefinita è stata la replica. Le organizzazioni pianificavano routine di integrazione notturne per trasferire cataloghi prodotti, saldi di magazzino e storici delle fatture direttamente in Dataverse, così che gli utenti potessero accedere a tutto in un unico punto.

Tuttavia, questa strategia di replica porta con sé gravi zavorre architetturali. I limiti di archiviazione aumentano, il database si gonfia rapidamente e, soprattutto, i dati obsoleti introducono un rischio operativo. Se un addetto al magazzino spedisce dieci unità di un articolo critico all'ora di pranzo, una tabella replicata in Dataverse continuerà a mostrare quelle dieci unità fino alla successiva sincronizzazione batch programmata. I venditori finiscono quindi per proporre a clienti frustrati merce non disponibile, con conseguenti annullamenti d'ordine e perdita di fiducia. Le tabelle standard richiedono la piena titolarità dei dati che contengono, e per questo sono una scelta poco adatta alle metriche operative in rapida evoluzione, di competenza di sistemi aziendali specializzati.

Confronto tra tabelle standard e tabelle virtuali

Comprendere le differenze operative tra le tabelle standard di Dataverse e le tabelle virtuali aiuta a capire quando adottare ciascuna architettura. La distinzione va ben oltre la semantica tecnica: determina la titolarità del sistema, i flussi di lavoro degli utenti e il carico di manutenzione.

Tabelle standard di Dataverse

Le tabelle standard, come Account, Contatti e Opportunità, sono elementi nativi dell'ecosistema Dataverse. Dataverse crea le tabelle del database, gestisce l'archiviazione fisica, applica i modelli di sicurezza a livello di tabella ed esegue nativamente logica di business, plug-in e flussi di lavoro sui record. Quando un utente crea o aggiorna un record, Dataverse è l'autorità definitiva. Il livello applicativo e il livello di archiviazione sono completamente unificati.

Tabelle virtuali

Le tabelle virtuali funzionano più come un catalogo di una biblioteca o come un feed video protetto. Dataverse contiene lo schema, le definizioni delle colonne e i metadati necessari per presentare un'interfaccia utente familiare nelle app basate su modello, ma non memorizza i record veri e propri. Quando un utente apre una visualizzazione o applica un filtro, Dataverse traduce la richiesta, interroga il sistema esterno tramite un provider di dati e visualizza al volo la risposta in tempo reale. L'applicazione esterna resta l'unica vera responsabile del ciclo di vita del record.

Valutare compromessi e limitazioni operative

Sebbene le tabelle virtuali risolvano l'incubo della sincronizzazione, introducono vincoli specifici che sviluppatori e amministratori devono valutare con attenzione. Poiché i dati sottostanti non risiedono in Dataverse, alcune funzionalità della piattaforma non si comportano come farebbero con le tabelle standard.

Ricerca avanzata, plug-in complessi lato server, campi di riepilogo e flussi di lavoro asincroni in background possono comportarsi in modo imprevedibile o non funzionare affatto se presuppongono la persistenza locale dei dati. Inoltre, le prestazioni dipendono direttamente dalla salute e dalla reattività dell'API o dell'origine dati esterna. Se l'applicazione ERP o di magazzino esterna presenta latenza o va offline, le tabelle virtuali corrispondenti in Dynamics 365 si bloccheranno o genereranno errori di connessione.

Anche la modellazione della sicurezza richiede un'attenta pianificazione. I ruoli di sicurezza di Dataverse possono controllare chi visualizza o modifica la definizione della tabella virtuale, ma la sicurezza a livello di riga deve spesso essere applicata a livello di API esterna o tramite provider di dati personalizzati, per garantire che gli utenti accedano solo ai record autorizzati.

Conclusione

La scelta tra tabelle standard di Dataverse e tabelle virtuali dipende in ultima analisi da chi possiede il ciclo di vita dei dati e dal fatto che gli utenti abbiano bisogno di una memorizzazione locale persistente o di una semplice visibilità contestuale. Mappando le origini dati esterne invece di replicarle, le organizzazioni possono mantenere un'area di lavoro unica e pulita in Dynamics 365, senza trasformare Dataverse in una discarica disordinata di tabelle di database duplicate. Per approfondire i building block fondamentali di questo approccio all'integrazione, non perdere la possibilità di ascoltare l'episodio completo e di iscriverti al podcast per altri approfondimenti pratici sul cloud.

Domande frequenti

Le tabelle virtuali consumano spazio di archiviazione di Dataverse?

No. Poiché le tabelle virtuali memorizzano in Dataverse solo definizioni di tabella, metadati e schemi, mentre i record effettivi restano nel sistema esterno, non consumano la capacità di archiviazione del database Dataverse dell'organizzazione.

Gli utenti possono modificare i record visualizzati tramite una tabella virtuale?

Sì, a condizione che il provider di dati sottostante e il sistema esterno supportino le operazioni di scrittura. I provider OData v4 integrati e le integrazioni di Finance and Operations possono supportare le azioni di creazione, aggiornamento ed eliminazione, anche se il sistema esterno applica comunque le proprie regole di convalida.

Cosa succede se l'origine dati esterna va offline?

Se l'applicazione esterna o la relativa API non è disponibile, gli utenti che visualizzano la tabella virtuale in Dynamics 365 riscontreranno errori di caricamento o vedranno griglie vuote, poiché le query in tempo reale non riescono a recuperare i record esterni.

Le tabelle virtuali sono la stessa cosa delle entità virtuali?

Sì. "Entità virtuali" è il termine legacy usato nella documentazione e nelle configurazioni Microsoft meno recenti, mentre "tabelle virtuali" è la terminologia ufficiale attuale. L'architettura e i concetti sottostanti restano identici.