Nozioni di base sulla composizione dello schema
Creato per:
- Sviluppatore
Scopri gli schemi Experience Data Model (XDM) e gli elementi di base, i principi e le best practice per la composizione di schemi in Adobe Experience Platform. Per informazioni generali su XDM e sul suo utilizzo in Experience Platform, consulta la Panoramica del sistema XDM.
Informazioni sugli schemi
Uno schema è un set di regole che rappresentano e convalidano la struttura e il formato dei dati. A un livello avanzato, gli schemi forniscono una definizione astratta di un oggetto reale (ad esempio una persona) e delineano quali dati includere in ogni istanza di tale oggetto (ad esempio nome, cognome, compleanno e così via).
Oltre a descrivere la struttura dei dati, gli schemi applicano vincoli e aspettative ai dati in modo che possano essere convalidati durante gli spostamenti tra sistemi diversi. Queste definizioni standard consentono di interpretare i dati in modo coerente, indipendentemente dall’origine, ed eliminano la necessità di traduzione tra le applicazioni.
Experience Platform mantiene questa normalizzazione semantica utilizzando gli schemi. Gli schemi sono il metodo standard per descrivere i dati in Experience Platform che consentono il riutilizzo di tutti i dati conformi agli schemi in un’organizzazione senza conflitti o anche la condivisione tra più organizzazioni.
Gli schemi XDM sono ideali per memorizzare grandi quantità di dati complessi in un formato autonomo. Consulta le sezioni su oggetti incorporati e big data nell'appendice di questo documento per ulteriori informazioni su come XDM esegue questa operazione.
Flussi di lavoro basati su schema in Experience Platform
La standardizzazione è un concetto chiave alla base di Experience Platform. XDM, gestito da Adobe, è un tentativo di standardizzare i dati sulla customer experience e definire schemi standard per la gestione della customer experience.
L'infrastruttura su cui viene generato Experience Platform, nota come XDM System, semplifica i flussi di lavoro basati su schema e include Schema Registry, Schema Editor, i metadati dello schema e i modelli di consumo del servizio. Per ulteriori informazioni, consulta la Panoramica del sistema XDM.
L’utilizzo degli schemi in Experience Platform offre diversi vantaggi chiave. In primo luogo, gli schemi consentono una migliore governance dei dati e la loro minimizzazione, il che è particolarmente importante con le normative sulla privacy. In secondo luogo, la creazione di schemi con i componenti standard di Adobe consente di ottenere informazioni predefinite e l’utilizzo di servizi AI/ML con personalizzazioni minime. Infine, gli schemi forniscono l’infrastruttura necessaria per condividere informazioni approfondite sui dati e orchestrare in modo efficiente.
Pianificazione dello schema
Il primo passaggio nella creazione di uno schema consiste nel determinare il concetto, o oggetto reale, che si sta tentando di acquisire all’interno dello schema. Dopo aver identificato il concetto che si sta tentando di descrivere, iniziare a pianificare lo schema pensando ad aspetti quali il tipo di dati, i potenziali campi di identità e l'evoluzione futura dello schema.
Comportamenti dei dati in Experience Platform
I dati destinati all’utilizzo in Experience Platform sono raggruppati in due tipi di comportamento:
- Dati record: fornisce informazioni sugli attributi di un oggetto. Un soggetto potrebbe essere un'organizzazione o un individuo.
- Dati della serie temporale: fornisce un'istantanea del sistema nel momento in cui è stata eseguita un'azione direttamente o indirettamente da un oggetto record.
Tutti gli schemi XDM descrivono dati che possono essere classificati come record o serie temporali. Il comportamento dei dati di uno schema è definito dalla classe dello schema, che viene assegnata a uno schema al momento della creazione. Le classi XDM sono descritte più avanti in questo documento.
Sia gli schemi record che le serie temporali contengono una mappa di identità (xdm:identityMap). Questo campo contiene la rappresentazione dell’identità di un soggetto, tratta dai campi contrassegnati come "Identità" come descritto nella sezione successiva.
Identità
Gli schemi vengono utilizzati per acquisire i dati in Experience Platform. Questi dati possono essere utilizzati in più servizi per creare una singola vista unificata di una singola entità. Pertanto, durante la progettazione di schemi per le identità dei clienti, è importante considerare quali campi possono essere utilizzati per identificare un soggetto, indipendentemente da dove possono provenire i dati.
Per facilitare questo processo, i campi chiave all’interno degli schemi possono essere contrassegnati come identità. Al momento dell'acquisizione dei dati, i dati contenuti in tali campi vengono inseriti nel "grafo identità" dell'utente. È quindi possibile accedere ai dati del grafico da Real-Time Customer Profile e altri servizi Experience Platform per fornire una visualizzazione combinata di ogni singolo cliente.
I campi comunemente contrassegnati come "Identità" includono: indirizzo e-mail, numero di telefono, Experience Cloud ID (ECID), ID CRM o altri campi ID univoci. Considera eventuali identificatori univoci specifici dell'organizzazione, in quanto potrebbero essere validi anche per i campi "Identity".
È importante considerare le identità dei clienti durante la fase di pianificazione dello schema per garantire che i dati vengano raccolti per creare il profilo più solido possibile. Per ulteriori informazioni su come le informazioni sulle identità possono aiutarti a fornire esperienze digitali ai tuoi clienti, consulta la Panoramica del servizio Identity. Consulta il documento sulle best practice per la modellazione dati per suggerimenti sull'utilizzo delle identità durante la creazione di uno schema.
Esistono due modi per inviare dati di identità ad Experience Platform:
- Aggiunta di descrittori di identità ai singoli campi tramite l'interfaccia utente dell'editor di schemi o utilizzando l'API del Registro di sistema dello schema
- Utilizzo di un campo
identityMap
identityMap
identityMap è un campo di tipo mappa che descrive i vari valori di identità di un individuo, insieme ai relativi spazi dei nomi associati. Questo campo può essere utilizzato per fornire informazioni sull’identità per gli schemi, anziché definire valori di identità all’interno della struttura dello schema stesso.
L'inconveniente principale dell'utilizzo di identityMap è che le identità diventano incorporate nei dati e di conseguenza meno visibili. Se acquisisci dati non elaborati, devi invece definire singoli campi di identità all’interno della struttura dello schema effettiva.
NOTEidentityMap può essere utilizzato come schema di origine in una relazione, ma non come schema di riferimento. Questo perché tutti gli schemi di riferimento devono avere un’identità visibile che può essere mappata in un campo di riferimento all’interno dello schema di origine. Per ulteriori informazioni sui requisiti degli schemi di origine e di riferimento, consulta la guida dell'interfaccia utente in relazioni.Tuttavia, le mappe di identità possono essere utili se per uno schema è presente un numero variabile di identità o se si desidera inserire dati da origini che memorizzano le identità (ad esempio Airship o Adobe Audience Manager). Inoltre, le mappe di identità sono necessarie se si utilizza Adobe Experience Platform Mobile SDK.
Di seguito è riportato un esempio di mappa di identità semplice:
"identityMap": {
"email": [
{
"id": "jsmith@example.com",
"primary": true
}
],
"ECID": [
{
"id": "87098882279810196101440938110216748923",
"primary": false
},
{
"id": "55019962992006103186215643814973128178",
"primary": false
}
],
"CRMID": [
{
"id": "2e33192000007456-0365c00000000000",
"primary": false
}
]
}
Come illustrato nell'esempio precedente, ogni chiave nell'oggetto identityMap rappresenta uno spazio dei nomi di identità. Il valore di ogni chiave è una matrice di oggetti che rappresenta i valori di identità (id) per il rispettivo spazio dei nomi. Consulta la documentazione di Identity Service per un elenco di spazi dei nomi di identità standard riconosciuti dalle applicazioni Adobe.
NOTEprimary). È sufficiente impostare le identità primarie per gli schemi da utilizzare in Real-Time Customer Profile. Per ulteriori informazioni, consulta la sezione sugli schemi di unione.Principi di evoluzione dello schema
Con l’evolversi della natura delle esperienze digitali, devono evolversi anche gli schemi utilizzati per rappresentarle. Uno schema ben progettato è quindi in grado di adattarsi ed evolvere secondo necessità, senza causare modifiche distruttive alle versioni precedenti dello schema.
Poiché mantenere la compatibilità con le versioni precedenti è fondamentale per l’evoluzione dello schema, Experience Platform applica un principio di controllo delle versioni puramente additivo. Questo principio garantisce che eventuali revisioni allo schema risultino solo in aggiornamenti e modifiche non distruttivi. In altre parole, le modifiche che causano interruzioni non sono supportate.
NOTELa tabella seguente suddivide le modifiche supportate durante la modifica di schemi, gruppi di campi e tipi di dati:
- Aggiunta di nuovi campi alla risorsa
- Impostazione di un campo obbligatorio come facoltativo
- Introduzione di nuovi campi obbligatori*
- Modifica del nome visualizzato e della descrizione della risorsa
- Abilitazione dello schema per la partecipazione al profilo
- Rimozione dei campi definiti in precedenza
- Ridenominazione o ridefinizione di campi esistenti
- Rimozione o limitazione dei valori di campo precedentemente supportati
- Spostamento dei campi esistenti in una posizione diversa nella struttura
- Eliminazione dello schema
- Disabilitazione dello schema dalla partecipazione al profilo
*Fare riferimento alla sezione seguente per importanti considerazioni relative all'impostazione di nuovi campi obbligatori.
Campi obbligatori
I singoli campi dello schema possono essere contrassegnati come obbligatori, il che significa che qualsiasi record acquisito deve contenere i dati in tali campi per superare la convalida. Ad esempio, l’impostazione del campo di identità principale di uno schema come richiesto può contribuire a garantire che tutti i record acquisiti partecipino a Real-Time Customer Profile. Allo stesso modo, l’impostazione di un campo marca temporale come richiesto garantisce che tutti gli eventi delle serie temporali siano conservati in modo cronologico.
IMPORTANTnull o valori vuoti per nessun campo acquisito. Se non è presente alcun valore per un particolare campo in un record o in un evento, la chiave per tale campo deve essere esclusa dal payload di acquisizione.Impostazione dei campi come richiesto dopo l’acquisizione
Se un campo è stato utilizzato per acquisire i dati e non è stato originariamente impostato come richiesto, è possibile che per alcuni record sia presente un valore Null. Se imposti questo campo come obbligatorio dopo l’acquisizione, tutti i record futuri devono contenere un valore per questo campo, anche se i record storici possono essere nulli.
Quando imposti un campo precedentemente facoltativo come richiesto, tieni presente quanto segue:
- Se esegui una query sui dati storici e scrivi i risultati in un nuovo set di dati, alcune righe non riusciranno perché contengono valori nulli per il campo richiesto.
- Se il campo fa parte di Real-Time Customer Profile e si esportano dati prima di impostarlo come necessario, per alcuni profili potrebbe essere null.
- Puoi utilizzare l’API Schema Registry per visualizzare un registro delle modifiche con marca temporale per tutte le risorse XDM in Experience Platform, compresi i nuovi campi obbligatori. Per ulteriori informazioni, consulta la guida dell'endpoint del registro di controllo.
Schemi e acquisizione di dati
Per acquisire dati in Experience Platform, è necessario prima creare un set di dati. I set di dati sono i blocchi predefiniti per la trasformazione e il tracciamento dei dati per Catalog Service e in genere rappresentano tabelle o file che contengono dati acquisiti. Tutti i set di dati si basano su schemi XDM esistenti, che forniscono vincoli per ciò che i dati acquisiti devono contenere e per come devono essere strutturati. Per ulteriori informazioni, consulta la panoramica su Acquisizione dati Adobe Experience Platform.
Blocchi predefiniti di uno schema
Experience Platform utilizza un approccio di composizione in cui i blocchi predefiniti standard vengono combinati per creare schemi. Questo approccio promuove la riutilizzabilità dei componenti esistenti e favorisce la standardizzazione nel settore per supportare schemi e componenti dei fornitori in Experience Platform.
Gli schemi vengono composti utilizzando la seguente formula:
Gruppo campi classe + schema;ast; = Schema XDM
*Uno schema è composto da una classe e da zero o più gruppi di campi dello schema. Ciò significa che è possibile comporre uno schema di set di dati senza utilizzare affatto i gruppi di campi.
Classe
La composizione di uno schema inizia assegnando una classe. Le classi definiscono gli aspetti comportamentali dei dati che lo schema conterrà (record o serie temporali). Inoltre, le classi descrivono il minor numero di proprietà comuni che tutti gli schemi basati su tale classe dovrebbero includere e forniscono un modo per unire più set di dati compatibili.
La classe di uno schema determina quali gruppi di campi sono idonei per l’utilizzo in tale schema. Questo argomento viene discusso più dettagliatamente nella sezione successiva.
Adobe fornisce diverse classi XDM standard ("core"). Due di queste classi, XDM Individual Profile e XDM ExperienceEvent, sono necessarie per quasi tutti i processi Experience Platform a valle. Oltre a queste classi principali, puoi anche creare classi personalizzate per descrivere casi d’uso più specifici per la tua organizzazione. Le classi personalizzate vengono definite da un’organizzazione quando non sono disponibili classi core definite da Adobe per descrivere un caso d’uso univoco.
La schermata seguente illustra come le classi sono rappresentate nell’interfaccia utente di Experience Platform. Poiché lo schema di esempio visualizzato non contiene gruppi di campi, tutti i campi visualizzati vengono forniti dalla classe dello schema (Profilo individuale XDM).
Per l'elenco più aggiornato delle classi XDM standard disponibili, fare riferimento al archivio XDM ufficiale. In alternativa, se preferisci visualizzare le risorse nell'interfaccia utente, consulta la guida su esplorazione dei componenti XDM.
Gruppo di campi
Un gruppo di campi è un componente riutilizzabile che definisce uno o più campi che implementano determinate funzioni come i dati personali, le preferenze di hotel o l’indirizzo. I gruppi di campi sono destinati a essere inclusi come parte di uno schema che implementa una classe compatibile.
I gruppi di campi definiscono con quali classi sono compatibili, in base al comportamento dei dati che rappresentano (record o serie temporali). Ciò significa che non tutti i gruppi di campi sono disponibili per l'utilizzo con tutte le classi.
Experience Platform include molti gruppi di campi standard di Adobe, consentendo ai fornitori di definire gruppi di campi per i propri utenti e ai singoli utenti di definire gruppi di campi per i propri concetti specifici.
Ad esempio, per acquisire dettagli quali "Nome" e "Indirizzo principale" per lo schema "Membri fedeltà", è possibile utilizzare gruppi di campi standard che definiscono tali concetti comuni. Tuttavia, concetti più specifici dell’organizzazione (ad esempio dettagli del programma fedeltà personalizzato o attributi di prodotto) che potrebbero non essere coperti dai gruppi di campi standard. In questo caso, è necessario definire un proprio gruppo di campi per acquisire queste informazioni.
NOTEGli schemi sono composti da "zero o più" gruppi di campi, pertanto puoi comporre uno schema valido senza utilizzare alcun gruppo di campi.
La schermata seguente illustra come i gruppi di campi sono rappresentati nell’interfaccia utente di Experience Platform. Un singolo gruppo di campi (Dettagli demografici) viene aggiunto a uno schema in questo esempio, che fornisce un raggruppamento di campi alla struttura dello schema.
Per l'elenco più aggiornato dei gruppi di campi XDM standard disponibili, fare riferimento al archivio XDM ufficiale. In alternativa, se preferisci visualizzare le risorse nell'interfaccia utente, consulta la guida su esplorazione dei componenti XDM.
NOTETipo di dati
I tipi di dati vengono utilizzati come tipi di campi di riferimento nelle classi o negli schemi allo stesso modo dei campi letterali di base. La differenza fondamentale consiste nel fatto che i tipi di dati possono definire più sottocampi nello stesso modo dei gruppi di campi. La differenza chiave tra di essi è che i tipi di dati possono essere inclusi ovunque in uno schema aggiungendolo come "tipo di dati" di un campo. Mentre i gruppi di campi sono compatibili solo con determinate classi, i tipi di dati possono essere inclusi in qualsiasi classe padre o gruppo di campi.
NOTEExperience Platform fornisce diversi tipi di dati comuni come parte di Schema Registry per supportare l'utilizzo di modelli standard per la descrizione di strutture di dati comuni. Questo è spiegato più dettagliatamente nelle esercitazioni del registro degli schemi e diventerà più chiaro man mano che si seguono i passaggi per definire i tipi di dati.
La schermata seguente illustra come i tipi di dati sono rappresentati nell’interfaccia utente di Experience Platform. Uno dei campi forniti dal gruppo di campi Dettagli demografici utilizza il tipo di dati "Oggetto", come indicato dal testo che segue il carattere barra verticale (|) accanto al nome del campo. Questo particolare tipo di dati fornisce diversi sottocampi che si riferiscono al nome di una singola persona, un costrutto che può essere riutilizzato per altri campi in cui è necessario acquisire il nome di una persona.
Per l'elenco più aggiornato dei tipi di dati XDM standard disponibili, fare riferimento al archivio XDM ufficiale. In alternativa, se preferisci visualizzare le risorse nell'interfaccia utente, consulta la guida su esplorazione dei componenti XDM.
NOTECampo
Un campo è il blocco predefinito più semplice di uno schema. I campi forniscono vincoli relativi al tipo di dati che possono contenere definendo un tipo di dati specifico. Questi tipi di dati di base definiscono un singolo campo, mentre i tipi di dati precedentemente menzionati ti consentono di definire più sottocampi e di riutilizzare la stessa struttura a più campi in vari schemi. Pertanto, oltre a definire il "tipo di dati" di un campo come uno dei tipi di dati definiti nel Registro di sistema, Experience Platform supporta anche i seguenti tipi scalari di base:
- Stringa
- Intero
- Doppio
- Booleano
- Array
- Oggetto
TIPGli intervalli validi di questi tipi scalari possono essere ulteriormente vincolati a determinati pattern, formati, minimi/massimi o valori predefiniti. Utilizzando questi vincoli, è possibile rappresentare un'ampia gamma di tipi di campo più specifici, tra cui:
- Enumerazione
- Lungo
- Breve
- Byte
- Data
- Data-ora
- Mappa
NOTEEsempio di composizione
Gli schemi vengono creati utilizzando un modello di composizione e rappresentano il formato e la struttura dei dati da acquisire in Experience Platform. Come indicato in precedenza, questi schemi sono composti da una classe e da zero o più gruppi di campi compatibili con tale classe.
Ad esempio, uno schema che descrive gli acquisti effettuati in un punto vendita al dettaglio potrebbe essere denominato "Transazioni store". Lo schema implementa la classe XDM ExperienceEvent combinata con il gruppo di campi Commerce standard e un gruppo di campi Informazioni prodotto definito dall'utente.
Un altro schema che tiene traccia del traffico del sito Web potrebbe essere denominato "Visite Web". Implementa anche la classe XDM ExperienceEvent, ma questa volta combina il gruppo di campi Web standard.
Il diagramma seguente mostra questi schemi e i campi con il contributo di ciascun gruppo di campi. Contiene inoltre due schemi basati sulla classe XDM Individual Profile, incluso lo schema "Membri fedeltà" menzionato in precedenza in questa guida.
Unione
Experience Platform consente di comporre schemi per casi d’uso specifici, ma ti consente anche di visualizzare un’"unione" di schemi per un tipo di classe specifico. Il diagramma precedente mostra due schemi basati sulla classe ExperienceEvent XDM e due schemi basati sulla classe XDM Individual Profile. L'unione mostrata di seguito aggrega i campi di tutti gli schemi che condividono la stessa classe (XDM ExperienceEvent e XDM Individual Profile, rispettivamente).
Attivando uno schema da utilizzare con Real-Time Customer Profile, viene incluso nell'unione per quel tipo di classe. Profile offre profili solidi e centralizzati degli attributi del cliente e un account con marca temporale per ogni evento che il cliente ha avuto in qualsiasi sistema integrato con Experience Platform. Profile utilizza la visualizzazione unione per rappresentare questi dati e fornire una visualizzazione olistica di ogni singolo cliente.
Per ulteriori informazioni sull'utilizzo di Profile, vedere Panoramica del profilo cliente in tempo reale.
Mappatura dei file di dati su schemi XDM
Tutti i file di dati acquisiti in Experience Platform devono essere conformi alla struttura di uno schema XDM. Per ulteriori informazioni su come formattare i file di dati per rispettare le gerarchie XDM (inclusi i file di esempio), consulta il documento su trasformazioni ETL di esempio. Per informazioni generali sull'acquisizione di file di dati in Experience Platform, consulta la panoramica sull'acquisizione batch.
Schemi per tipi di pubblico esterni
Se stai inserendo in Experience Platform tipi di pubblico da sistemi esterni, devi utilizzare i seguenti componenti per acquisirli negli schemi:
- Definizione segmento classe: utilizzare questa classe standard per acquisire gli attributi chiave di una definizione segmento esterna.
- Dettagli sull'iscrizione al segmento gruppo di campi: aggiungi questo gruppo di campi allo schema Profilo individuale XDM per associare i profili dei clienti a tipi di pubblico specifici.
Passaggi successivi
Ora che hai compreso le nozioni di base sulla composizione dello schema, puoi iniziare a esplorare e creare schemi utilizzando Schema Registry.
Per esaminare la struttura delle due classi XDM di base e dei relativi gruppi di campi compatibili di uso comune, consulta la seguente documentazione di riferimento:
Schema Registry viene utilizzato per accedere a Schema Library in Adobe Experience Platform e fornisce un'interfaccia utente e un'API RESTful da cui tutte le risorse della libreria disponibili sono accessibili. Schema Library contiene le risorse del settore definite da Adobe, le risorse del fornitore definite dai partner Experience Platform e le classi, i gruppi di campi, i tipi di dati e gli schemi composti dai membri dell'organizzazione.
Per iniziare a comporre lo schema utilizzando l'interfaccia utente, seguire l'esercitazione Schema Editor per creare lo schema "Membri fedeltà" menzionato in questo documento.
Per iniziare a utilizzare l'API Schema Registry, leggere la Guida per gli sviluppatori dell'API del registro degli schemi. Dopo aver letto la guida per gli sviluppatori, segui i passaggi descritti nell'esercitazione su creazione di uno schema tramite l'API Schema Registry.
Appendice
Le sezioni seguenti contengono informazioni aggiuntive sui principi della composizione dello schema.
Tabelle relazionali e oggetti incorporati
Quando si lavora con i database relazionali, le best practice prevedono la normalizzazione dei dati o la suddivisione di un’entità in parti discrete da visualizzare in più tabelle. Per leggere i dati nel loro insieme o aggiornare l'entità, è necessario eseguire operazioni di lettura e scrittura in più tabelle singole utilizzando JOIN.
Utilizzando gli oggetti incorporati, gli schemi XDM possono rappresentare direttamente dati complessi e memorizzarli in documenti autonomi con una struttura gerarchica. Uno dei principali vantaggi di questa struttura è che consente di eseguire query sui dati senza dover ricostruire l’entità tramite join costosi su più tabelle denormalizzate. Non esistono restrizioni rigide sul numero di livelli consentiti per la gerarchia dello schema.
Schemi e big data
I sistemi digitali moderni generano una grande quantità di segnali comportamentali (dati sulle transazioni, registri web, internet delle cose, display e così via). Questi big data offrono opportunità straordinarie per ottimizzare le esperienze, ma sono difficili da utilizzare a causa della scala e della varietà dei dati. Per ottenere valore dai dati, la struttura, il formato e le definizioni devono essere standardizzati in modo da poter essere elaborati in modo coerente ed efficiente.
Gli schemi risolvono questo problema consentendo l’integrazione dei dati da più origini, la standardizzazione attraverso strutture e definizioni comuni e la condivisione tra le diverse soluzioni. Ciò consente ai processi e ai servizi successivi di rispondere a qualsiasi tipo di domanda relativa ai dati. Si allontana dall’approccio tradizionale alla modellazione dei dati, in cui tutte le domande da porre sui dati sono note in anticipo e i dati sono modellati in modo da essere conformi a tali aspettative.
Oggetti e campi in formato libero
Durante la progettazione degli schemi è necessario tenere presenti alcuni fattori chiave per la scelta degli oggetti rispetto ai campi in formato libero:
Oggetti
Di seguito sono elencati i pro e i contro dell’utilizzo di oggetti su campi in formato libero.
Pro:
- Gli oggetti vengono utilizzati in modo ottimale quando si desidera creare un raggruppamento logico di determinati campi.
- Gli oggetti organizzano lo schema in modo più strutturato.
- Gli oggetti aiutano indirettamente a creare una buona struttura di menu nell’interfaccia utente di Segment Builder. I campi raggruppati all’interno dello schema si riflettono direttamente nella struttura di cartelle fornita nell’interfaccia utente di Segment Builder.
Contro:
- I campi diventano più nidificati.
- Quando si utilizza Adobe Experience Platform Query Service, è necessario fornire stringhe di riferimento più lunghe ai campi di query nidificati negli oggetti.
Campi in formato libero
Di seguito sono elencati i pro e i contro dell’utilizzo di campi in formato libero sugli oggetti.
Pro:
- I campi in formato libero vengono creati direttamente sotto l'oggetto principale dello schema (
_tenantId), aumentando la visibilità. - Le stringhe di riferimento per i campi in formato libero tendono a essere più brevi quando si utilizza Query Service.
Contro:
- La posizione dei campi in formato libero all’interno dello schema è ad hoc, ovvero vengono visualizzati in ordine alfabetico nell’Editor di schema. Questo può rendere gli schemi meno strutturati e simili campi a forma libera possono finire per essere molto separati a seconda del loro nome.