Più di un database

🌐 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)

Immagine generata con l'IA

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

Modulo 1 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Successivo: Guarda alla nave madre: i modelli dati standard

La domanda a cui risponde questo modulo: Cosa rende Salesforce diversa da un database tradizionale?

Se fai l’amministratore Salesforce da un po’, sai già come creare un oggetto. Imposta, Gestione oggetti, Nuovo oggetto personalizzato. Gli dai un nome, aggiungi qualche campo, costruisci un layout di pagina, e dieci minuti dopo gli utenti possono lavorarci.

Ma cosa è successo davvero quando hai cliccato Salva?

Se vieni dal mondo dei database, probabilmente immagini che Salesforce sia andata a creare una nuova tabella. Non l’ha fatto. E capire perché è uno dei punti in cui inizi a passare dal pensare da amministratore o da sviluppatore al pensare da architetto.

Salesforce memorizza dati, certo; sotto ci sono dei database. Ma Salesforce non è un database con una bella schermata sopra. È una piattaforma applicativa guidata dai metadati, e questa distinzione dà forma a quasi ogni decisione di questo corso.

La piattaforma ha una forma

Nel capitolo 2 abbiamo costruito il modello senza preoccuparci affatto di Salesforce. Era voluto: abbiamo ascoltato i sostantivi, costruito il modello concettuale, aggiunto attributi, chiavi e relazioni, e solo allora ci siamo chiesti come Salesforce dovesse implementarlo. Ora dobbiamo capire la cosa su cui lo stiamo implementando.

Uso una frase semplice per questo: la piattaforma ha una forma. Salesforce ci dà oggetti, campi, relazioni, sicurezza, automazione, API, transazioni, reportistica e ricerca, e sono tutti collegati. Quando creo un oggetto, non sto solo creando un posto dove mettere delle righe. Sto creando qualcosa che partecipa al modello di sicurezza, su cui l’automazione può agire, che le API espongono, che i report possono usare, a cui altri oggetti possono collegarsi, e da cui utenti, integrazioni e, sempre di più, agenti dipenderanno. È molto più di una tabella.

I metadati sono il progetto

Pensa a un edificio. C’è l’edificio stesso, e c’è il progetto che lo descrive: dove sono le pareti, dove vanno le porte, come si collegano le stanze. Salesforce funziona allo stesso modo. La definizione di un oggetto è un metadato. La definizione di un campo è un metadato. Una relazione è un metadato. Gran parte di ciò che configuriamo in Imposta sono metadati, e la piattaforma li legge in fase di esecuzione per dare alla nostra org la sua struttura e il suo comportamento.

Salesforce descrive il cuore della piattaforma come al tempo stesso multitenant e guidato dai metadati: quando definiamo un oggetto o un campo, la definizione viene memorizzata come metadato, non come una nuova tabella o colonna fisica per la nostra org (Platform Multitenant Architecture (opens in a new tab)).

Quando lo insegno, apro il cofano. Salesforce non crea un nuovo database per te ogni volta che aggiungi un oggetto. Aggiunge un record alle proprie tabelle: una tabella degli oggetti, una tabella dei campi, una tabella dei dati, e tabelle pivot per indici e relazioni, il tutto indicizzato da un identificatore dell’org che tiene i dati della tua org separati da quelli di tutti gli altri. Quindi aggiungere un campo è solo aggiungere una voce. Ecco perché puoi crearne uno al volo, all’ora di pranzo, in produzione.

Spiega anche una cosa su cui molti inciampano. Quando scrivi SELECT Id, Name, Special__c FROM Account, sembra una sola tabella. Sotto, stai leggendo l’oggetto standard e il suo campo personalizzato da strutture diverse, quindi la piattaforma sta facendo una join che non hai mai scritto. Gli indici esistono, ma non funzionano come l’indice di un database tradizionale. Per l’esame non devi conoscere i meccanismi interni. Devi sapere però che ciò che vedi in Gestione oggetti non è un’immagine uno-a-uno delle tabelle fisiche, e che l’astrazione è al tempo stesso la forza della piattaforma e il motivo per cui si comporta come si comporta.

Click to enlarge

Guarda alla nave madre

Una delle cose che dico in aula è di guardare alla nave madre. Prima di inventare un modo complicato per fare qualcosa su Salesforce, guarda come lo fa Salesforce stessa.

Prendi Account. Non l’hai creato tu; l’ha creato Salesforce. Ma puoi aggiungergli campi, costruirci intorno automazioni, cambiarne i layout, esporlo tramite le API e collegargli altri oggetti. Gli oggetti personalizzati girano sullo stesso meccanismo, ed è per questo che oggetti standard e personalizzati sembrano così simili quando ci costruiamo sopra. In Apex condividono perfino una classe base, l’sObject.

È l’abitudine su cui si costruisce questo capitolo, e nel prossimo modulo guardiamo per bene: ai modelli dati standard che Salesforce ha già costruito per te.

Non stiamo costruendo accanto a Salesforce. La stiamo estendendo.

La tua API è arrivata con l’oggetto

Crea una tabella in un database tradizionale e hai una tabella. Se un’altra applicazione deve lavorarci, qualcuno ha altro lavoro da fare. Crea un oggetto su Salesforce, e la piattaforma lo capisce già attraverso i suoi livelli applicativi e di integrazione: usa gli stessi metadati per fornire le sue API REST e SOAP, quindi i record dell’oggetto si possono creare, leggere, aggiornare ed eliminare tramite queste API non appena l’oggetto esiste (Platform Multitenant Architecture (opens in a new tab)).

Non ho progettato un’API perché ho creato un oggetto. La piattaforma conosce l’oggetto, i suoi campi, i loro tipi, le sue relazioni e la sua sicurezza. È uno dei motivi per cui lo sviluppo su Salesforce va così veloce. È anche il motivo per cui creare un oggetto è una decisione più grande di quanto sembri: stai collegando una struttura a un’intera piattaforma applicativa. E vale anche al contrario. Chi viene da SQL Server o Oracle a volte mi chiede come caricare i dati direttamente nel database. Non puoi. Tutto passa dalle API.

Il condominio

Ora la parola che senti di continuo: multitenancy. Io la penso come un condominio.

Hai il tuo appartamento. I tuoi mobili sono tuoi, e la tua chiave non dovrebbe aprire la mia porta. Ma condividiamo l’edificio: l’elettricità, l’acqua, gli ascensori, l’atrio. La tua org sembra un ambiente tutto tuo, con i tuoi dati, i tuoi oggetti, la tua automazione. Sotto, Salesforce descrive ogni org come un tenant, isolando dati, metadati e logica di ciascun tenant mentre infrastruttura e servizi sono condivisi (Platform Multitenant Architecture (opens in a new tab)). È così che può dare a ogni cliente una piattaforma così personalizzabile senza gestire un’infrastruttura separata per ciascuno.

Ma condividere l’edificio ha conseguenze. Se un inquilino compra un condizionatore enorme e accende insieme asciugacapelli e forno, fa saltare il contatore, e l’intero piano resta al buio.

Non puoi prenderti l’ascensore

Resta nell’edificio ancora un minuto. Immagina che un residente annunci: “Mi serve l’ascensore dalle otto a mezzogiorno. Nessun altro può usarlo”. In un edificio condiviso non funziona, e non funziona nemmeno su Salesforce. Non si può permettere a un tenant di consumare risorse condivise senza limiti e peggiorare la piattaforma per tutti gli altri.

È da qui che vengono i limiti del governor (governor limits). Se hai sviluppato su Salesforce, probabilmente li hai incontrati come un elenco di numeri da memorizzare. Non voglio che li pensi così. Salesforce applica limiti a livello di transazione e di org perché il carico di lavoro di un tenant non monopolizzi le risorse di calcolo condivise (Architecture Basics (opens in a new tab)). Questa è l’architettura; ogni singolo limite ne è solo l’implementazione. Più avanti nel corso ci interesseranno limiti precisi perché cambiano un progetto. Per ora ricorda l’edificio: hai un’enorme libertà di ristrutturare il tuo appartamento. Non puoi prenderti l’ascensore.

Gli ID Salesforce fanno parte dell’astrazione

Ogni record Salesforce ha un’identità che la piattaforma capisce, l’ID del record, e funziona in tutte le funzionalità: l’interfaccia, le API, i report, l’automazione.

Nel capitolo 2 abbiamo detto che una buona chiave è unica, immutabile, priva di significato e mai un dato personale. L’ID Salesforce lo soddisfa per Salesforce. Ma non è la stessa cosa di una chiave di business. La tua azienda potrebbe avere ancora un numero cliente dell’ERP, una matricola o il numero d’ordine di un partner che ha un significato tra i sistemi. Non confondere “Salesforce sa quale record è questo” con “l’azienda sa quale cosa di business è questa”. Sono problemi di identità diversi, e il secondo torna con l’integrazione e i dati master.

Gli oggetti sono più che spazio di archiviazione

Ecco il cambio di prospettiva che voglio che tu faccia prima del resto di questo capitolo. Un oggetto non è solo un posto dove memorizzare dati. Un campo non è solo una colonna, e una relazione non è solo una chiave esterna. Uso i paragoni con i database quando insegno, perché si collegano a ciò che le persone sanno già. Ma se ci fermiamo lì, perdiamo l’architettura.

L’oggetto che scegliamo decide quali funzionalità arrivano con esso. Il tipo di campo influisce su convalida, integrazione, ricerca, reportistica e sul modo in cui gli altri sistemi leggono i dati. La relazione decide ciclo di vita, titolarità, condivisione ed eliminazione. Dove mettiamo i dati influisce su spazio di archiviazione, prestazioni e scala. E siccome tutto questo gira su una piattaforma condivisa, una scelta innocua con cento record può comportarsi in modo molto diverso con cento milioni. Affronteremo queste decisioni una alla volta.

Oltre l’esame: cosa cambia l’IA. Per anni, buoni nomi e buone descrizioni hanno aiutato il prossimo amministratore o sviluppatore a capire cosa avevamo costruito. Ora quel contesto lo leggono anche le macchine. Un sistema di IA che lavora con un campo chiamato Flag2__c ha lo stesso problema di un nuovo sviluppatore: cosa significa questa cosa? I metadati non sono più decorazione; fanno parte del modo in cui le macchine capiscono l’applicazione.

Cosa decide qui un architetto

• Sto progettando per la piattaforma su cui mi trovo davvero, o sto trattando Salesforce come un database generico?
• Quali parti del mio progetto sono concetti di business, e quali sono scelte di implementazione Salesforce?
• Quale comportamento della piattaforma arriva insieme alla struttura che sto per creare?
• Quali limiti sono espressioni dell’architettura condivisa, e quali daranno forma a questo progetto?
• Se questa struttura sarà difficile da cambiare in seguito, la sto trattando come una decisione architetturale?

Nel capitolo 2 abbiamo detto: non progettare partendo da Imposta. Ora conosci un altro motivo. Cliccare Nuovo oggetto personalizzato non ti dà solo una tabella; collega un altro pezzo della tua architettura a una piattaforma multitenant guidata dai metadati. Ma prima di decidere quale oggetto creare, c’è una domanda più basilare: questi dati dovrebbero proprio risiedere qui? È il prossimo argomento.

Per approfondire

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (in inglese), consultato il 2026-10-02, riverificato il 2026-10-12: le definizioni di oggetti e campi sono memorizzate come metadati, non come nuove tabelle; tabelle condivise (MT_Objects, MT_Fields, MT_Data, MT_Indexes) indicizzate per OrgID; gli stessi metadati forniscono le API REST e SOAP.
• Salesforce Architects, Architecture Basics (opens in a new tab) (in inglese), consultato il 2026-10-02, riverificato il 2026-10-12: limiti del governor e di esecuzione perché codice e transazioni “non monopolizzino le risorse di calcolo condivise”.