Ogni struttura è un impegno

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Capitolo 3 di Data Architect, Parte 1: Diventare un architetto dei dati. Precedente: Modellare i dati per il loro significato.

Ecco una domanda che faccio in ogni corso. Se qualcuno dice “lavoro con Salesforce”, qual è il nome API dell’oggetto prodotto?

È Product2. È la mia prima cartina di tornasole. A un certo punto Salesforce ha costruito l’oggetto prodotto, si è resa conto che non funzionava e ha dovuto lasciarlo indietro. Non poteva semplicemente toglierlo, così ha aggiunto Product2. Anche Salesforce convive con le sue vecchie strutture.

Salesforce si è anche lasciata spazio per crescere. I suoi oggetti standard non hanno prefissi né suffissi, e noi, le persone che personalizzano le org, non possiamo mai occupare quello spazio. Così Salesforce può continuare ad aggiungere oggetti senza mai scontrarsi con qualcosa che costruiamo noi.

Ecco la lezione: creare un oggetto richiede dieci minuti. Conviverci richiede anni. Ogni oggetto e ogni campo che aggiungi è un impegno. Occupa spazio di archiviazione. Accumula limiti. Riceve un modello di condivisione, che tu ne abbia progettato uno o no. Ha bisogno di una licenza per ogni persona che lo tocca. E ora lo legge anche l’IA, quindi come lo chiami e come lo descrivi decide cosa capisce un agente dei tuoi dati. Aggiungere è facile. Togliere è difficile.

Questo capitolo trasforma i mattoni di Salesforce in decisioni.

Immagine generata con l’IA.

Le strutture in sintesi

Salesforce ti offre sei posti dove tenere i dati. Li metto in una sola slide, perché il primo compito è sapere che esistono tutti:

Struttura	A cosa serve	Il rovescio della medaglia
Oggetti standard	Il modello di Salesforce: Account, Contatto, Opportunità, Caso, Asset e gli altri	Usali per ciò a cui sono destinati, o ti remeranno contro
Oggetti personalizzati	I dati del tuo business	Facili da creare, difficili da ritirare
Oggetti esterni	Dati che risiedono in un altro sistema, mostrati in Salesforce	Ogni accesso è una chiamata esterna (callout)
Big object	Volumi enormi che devi conservare ma apri di rado	Niente interfaccia né reportistica standard; interroghi tramite l’indice
File	Documenti, foto e altri contenuti	Lo spazio per i file sale in fretta
Allegati	Il vecchio modo di memorizzare i file	Legacy: usa i File

Sceglierne uno, però, è solo una parte. Prima della struttura viene la domanda su dove i dati dovrebbero risiedere in assoluto: sul core, referenziati dove si trovano già, o archiviati.

Il percorso di questo capitolo

Questo capitolo è grande, quindi è diviso in dieci parti. Ognuna si regge da sola. Nel capitolo 2 abbiamo deciso come dovrebbe essere il modello; qui decidiamo come dovrebbe vivere su Salesforce.

1. La piattaforma dati Salesforce: più di un database. Cosa rende Salesforce diversa, e perché la piattaforma ha una forma.
2. Guarda alla nave madre: i modelli dati standard. I modelli Sales e Service che Salesforce ha già costruito, i file, lo spazio di archiviazione e gli account personali.
3. Costruisci il tuo: gli oggetti personalizzati. Cosa decide la schermata Nuovo oggetto personalizzato, i campi che non hai creato tu, e come leggere qualsiasi nome API: standard, personalizzato o di un pacchetto gestito.
4. Dove risiedono questi dati? Sul core, referenziati o archiviati: deciso prima di creare qualsiasi oggetto.
5. Scegli l’oggetto giusto. Il test dell’adattamento pulito, il bagaglio che portano con sé gli oggetti standard, gli account personali e le licenze che decidono cosa le persone possono usare.
6. Anche i campi sono architettura. Tipo di campo per tipo di campo, i comportamenti che sorprendono, e perché ogni campo riceve una descrizione.
7. Le relazioni hanno conseguenze. Relazione di ricerca o master-dettaglio, tre livelli di profondità e due genitori di larghezza, l’oggetto di giunzione logico e l’oggetto di giunzione di Salesforce (Salesforce Junction Object), e i limiti che mordono.
8. Titolarità e ciclo di vita. Chi è titolare di un record, la tabella di condivisione in cui la titolarità diventa accesso, e cosa succede a un record nel corso della sua vita.
9. Mantenere i dati coerenti. La scala della coerenza: ogni livello ha un costo, e non si “corregge” mai lo storico per soddisfare una nuova regola.
10. Progetta il modello fisico Salesforce. Una porzione di Steve Trucking, dal modello logico a Salesforce, costruita passo dopo passo, con il ragionamento.

Quando hai finito, mettiti alla prova con la guida allo studio del capitolo: una checklist per l’esame, le abitudini che vanno oltre, le parole da conoscere e qualche domanda.

Cosa decide qui un architetto

• Cosa Salesforce modella già, prima di inventare qualsiasi cosa: guarda alla nave madre.
• Dove risiede ogni tipo di dato, sul core, referenziato o archiviato, prima di scegliere una struttura.
• Quale struttura lo contiene, sapendo a cosa rinuncia ciascuna.
• Come si relazionano gli oggetti, chi è titolare dei record, e cosa significa per l’accesso e la scala.
• Da quali licenze dipende il modello, verificate prima di progettare gli oggetti, non dopo.
• Come i dati restano coerenti, e quanto costa ogni livello di coerenza.

Oltre l’esame: la costruzione assistita dall’IA può creare oggetti e campi in pochi minuti. Quando aggiungere non costa quasi nulla, “ogni struttura è un impegno” conta di più, non di meno. Ogni modulo si chiude con ciò che l’IA cambia per quella decisione.

Per approfondire

• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Guida di Salesforce (in inglese)
• Standard User Licenses (opens in a new tab), Guida di Salesforce (in inglese)

Successivo: Capire i dati aziendali