Onde vivem estes dados?

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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)

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

Módulo 4 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Construa o seu: objetos personalizados · Próximo: Escolha o objeto certo

A pergunta que este módulo responde: antes de criar um objeto, onde deveriam realmente viver estes dados: no núcleo, no Salesforce, referenciados onde já estão, ou arquivados?

Deixe-me fazer uma pergunta. Chega-lhe à secretária um requisito novo. Qual é a primeira coisa que faz?

Se é como a maioria de nós, abre o Setup e cria um objeto personalizado. Eu entendo. Em dez minutos tem um separador, um layout de página e uma vista de lista. E eis o que digo em todas as turmas: no momento em que cria aquele objeto novo, já está a pensar como arquiteto, quer tenha essa intenção ou não. Porque cada objeto que cria é um compromisso. Ocupa armazenamento. Acumula limites. Ganha um modelo de partilha, quer tenha projetado um ou não. Precisa de uma licença para qualquer pessoa que lhe toque. E, depois de pessoas e integrações dependerem dele, boa sorte para o tirar.

Por isso a primeira decisão de arquitetura não é que objeto. É onde deveriam viver estes dados? Acerte nisso e o tipo de objeto quase se escolhe sozinho.

No núcleo e fora do núcleo

Primeiro, uma palavra que vou usar muito: núcleo (core). O núcleo é a plataforma Salesforce em que a sua org corre: a plataforma multitenant orientada por metadados do módulo 1, onde vivem os objetos de Sales e Service do módulo 2, e todos os objetos personalizados que constrói no módulo 3. Quando digo que os dados estão no núcleo (on core), quero dizer que estão armazenados na sua org, nos objetos dela.

Nem todos os dados vivem ali. O Data 360 guarda os dados num armazenamento próprio, fora dos objetos da sua org (é próximo do núcleo (near-core): gerido no núcleo, com os dados alojados fora do núcleo; mais no capítulo 4). E depois há tudo o que a sua empresa tem a correr e que nem sequer é Salesforce: o ERP, o data warehouse, o sistema de encomendas, a plataforma do parceiro. Tudo isso está fora do núcleo (off core). O Salesforce consegue chegar a esses dados, mostrá-los e usá-los, mas a sua org não os armazena.

No núcleo, há dois tipos de objetos que de facto guardam os seus registos: os sObjects, padrão e personalizados (__c), e os big objects (__b). Fora do núcleo, chega aos dados através dos objetos externos (__x) e das outras ferramentas de integração. Tenha presentes esses sufixos do módulo 3; dizem-lhe onde vive um dado só pelo nome.

Penso nisto como um escritório. Algumas coisas ficam na sua secretária, onde as usa todos os dias. Outras só precisa de as consultar no arquivo de outra pessoa. E outras vão para caixas na arrecadação das traseiras. Isso dá-me três respostas.

1. No núcleo: vive na sua secretária

Os dados são criados, alterados e usados no Salesforce todos os dias: contas, casos, oportunidades, ordens de trabalho. Guardá-los em sObjects é como guardá-los à frente, no escritório. É para isso que existem os objetos padrão e personalizados, e fica com tudo: layouts de página, partilha, automação, relatórios, pesquisa e, agora, as funcionalidades de IA construídas sobre o modelo de dados.

Mas a sua secretária não é de graça. Os dados no núcleo custam armazenamento, contado da forma como o Salesforce o conta, registo a registo, não coluna a coluna, e os documentos contam à parte, no armazenamento de ficheiros. Vimos as duas coisas no módulo 2. Grandes volumes de fotografias e digitalizações pertencem muitas vezes fora do núcleo, com o Salesforce a guardar só um link.

2. Referenciados: vivem no arquivo de outra pessoa

Os dados pertencem a outro sistema (o ERP, um data warehouse, uma plataforma de encomendas), e esse sistema continua a ser a fonte da verdade. Os utilizadores precisam de os ver no Salesforce, talvez relacioná-los com um registo, mas o Salesforce não precisa de uma cópia própria. Também vai ouvir chamar a isto dados virtuais: aparecem no Salesforce de forma virtual, sem nunca lá ficarem armazenados.

Isso são os objetos externos, através do Salesforce Connect. Gosto de dizer que tem ar de pato e anda como um pato, mas não é um pato. Aparece como um sObject: pode pô-lo em layouts de página e listas relacionadas, e relacioná-lo com os seus próprios registos através de relações de pesquisa externas e indiretas. Mas os dados não estão armazenados no núcleo. Sempre que lhe toca, faz uma chamada externa (callout). Abra um registo, carregue uma lista relacionada, corra um relatório, e o Salesforce vai lá perguntar ao outro sistema. Isso significa latência, e a sua página só está tão disponível quanto o sistema que tem por trás.

As pessoas queixam-se do custo da licença, por isso faça as contas como faço nas aulas. O Connect é licenciado por endpoint, e um endpoint pode trazer muitos objetos. Agora pergunte quanto custa construir e manter a alternativa: um componente personalizado, o código de callout por trás dele, e um programador de prevenção quando se estragar. Muitas vezes a licença sai mais barata, e os seus administradores conseguem configurá-la sem escrever uma linha de código. Onde não serve: dados que os seus utilizadores editam o dia todo, ou sobre os quais fazem muitos relatórios.

Os documentos também podem ser referenciados. Se um contrato já vive no SharePoint Online, no OneDrive, no Google Drive ou no Box, o Files Connect permite aos utilizadores chegarem a ele a partir do Salesforce sem o copiarem para dentro.

O Salesforce Connect não é a única forma de referenciar dados. Às vezes é lógica personalizada: código que chama o outro sistema em tempo real e mostra os dados dele na página, sem guardar cópia. Isso dá controlo total, e responsabilidade total pelo callout, pelos erros e pela manutenção. E o Data 360 também consegue federar sem copiar. Essa escolha tem o seu próprio capítulo (Virtualization, Federation, and Zero-Copy). Aqui, o ponto é a decisão em si: referencie, não copie.

3. Arquivados: vão para a arrecadação das traseiras

Histórico, registos de auditoria, transações antigas. Precisa de os guardar, às vezes durante anos, mas quase ninguém os abre. E este é o que as equipas vão adiando. Quando uma turma me diz que tem um objeto com 50 milhões de registos e pergunta porque haveria de arquivar, devolvo a pergunta: se não arquiva hoje, alguma vez vai arquivar? Com 50 milhões hoje, está a caminho dos 100, 150, 200 milhões.

Há duas arrecadações. Uma fica no núcleo: os big objects. Pense neles como guardar dados na garagem. Consegue guardar um número enorme de registos, mas não os consegue pôr num layout de página, não há interface nem relatórios padrão, e consulta-os pelo índice do big object, por correspondência exata ou por intervalo (Big Objects Best Practices (opens in a new tab), em inglês). A segurança é só por permissões de objeto e de campo, sem partilha de registos, e a automação não corre neles. Já usei o Salesforce Connect dezenas de vezes e os big objects só uma ou duas. Funcionam, mas são desajeitados, e já escrevi a minha quota de remendos para chegar aos dados. Por isso o meu conselho: faça um protótipo antes de os sugerir, e planeie como as pessoas vão encontrar os dados antes de escolher.

A outra arrecadação fica fora do núcleo: um data warehouse ou uma base de dados noutro lado (Designing for Scale). Muitas vezes essa é a melhor arrecadação, e não tem de ficar longe da vista. Os dados arquivados fora do núcleo podem continuar a aparecer em relatórios através de ferramentas como o Tableau, e podem continuar acessíveis a partir do Salesforce, pelo Salesforce Connect ou por outra forma de os virtualizar, quando alguém precisa de olhar para trás.

Deixe-me falar de um projeto em que acertámos nisto desde o início. Um cliente de retalho tinha mais de 1.200 unidades. Disseram-me: «Só fazemos cem marcações por dia numa loja. Nada de especial.» Então fiz as contas: cem por dia, seis dias por semana (uns 305 dias por ano), em 1.200 unidades, dá mais de 36 milhões de marcações por ano. Depois referiram que cada visita criava duas marcações, uma no balcão da frente e uma para as traseiras da loja: mais de 73 milhões de registos por ano. Depois quiseram cinco anos de histórico: mais de 360 milhões de registos, antes de qualquer crescimento. Ainda nem tínhamos entrado em produção, e eu já via o comboio a ir direto para a estação dos grandes volumes de dados. Por isso o arquivo foi construído antes de recolhermos uma única marcação: as marcações mais antigas iam para big objects, e o ecrã de pesquisa mostrava as marcações atuais com as arquivadas logo por baixo. Anos depois, continua a correr bem.

Click to enlarge

Na prática: Steve Trucking

A Steve Trucking é o nosso cenário recorrente: uma empresa familiar de entregas de última milha que vai buscar eletrodomésticos e eletrónica aos centros de distribuição de grandes retalhistas, e depois os entrega e instala em casa dos clientes. Quatro tipos dos seus dados, três respostas:

Dados	Onde vivem	Porquê
As entregas, equipas e marcações de hoje	No núcleo	Os expedidores e as equipas trabalham neles o dia todo
Os pormenores da encomenda do retalhista	Referenciados (ou uma cópia enxuta no núcleo)	O sistema do retalhista é a fonte da verdade
O histórico de entregas de três anos atrás	Arquivados	Guardados para reclamações e tendências; quase ninguém os abre
Fotografias das entregas	Fora do núcleo, com link	Milhares por dia; guardadas fora do Salesforce, com um link na entrega

Eis a mesma coisa como modelo de dados. A Entrega fica no núcleo, onde as pessoas trabalham nela o dia todo. Três anos depois, passa para o Histórico de entregas (Delivery History), um big object: ainda no núcleo, mas lá na arrecadação. A encomenda do parceiro aparece como um objeto externo, __x: o Salesforce relaciona a entrega com ela, mas os dados ficam no sistema do retalhista. E as fotografias vivem totalmente fora do núcleo, com um link a partir da entrega. Um modelo, três casas.

Click to enlarge

Todas as orgs reais têm os três. As que se complicam puseram tudo no núcleo, porque criar um objeto era o botão por defeito.

O que um arquiteto decide aqui

• A casa de cada tipo de dado, antes de projetar qualquer objeto: no núcleo, referenciado ou arquivado.
• A fonte da verdade. Se outro sistema é dono dos dados, o Salesforce não deveria tornar-se em silêncio um segundo mestre.
• O caminho de acesso a tudo o que está fora do núcleo. Dados referenciados precisam de uma fonte disponível e de latência aceitável; dados arquivados precisam de uma forma de as pessoas os encontrarem.
• O crescimento do armazenamento. Faça as contas agora (registos por dia, vezes crescimento, vezes retenção), não quando chegar o aviso de armazenamento.

Além do exame: a IA aumenta o que está em jogo no «no núcleo». As funcionalidades de IA e os agentes funcionam melhor com dados que a plataforma entende: dados em objetos padrão e personalizados, bem nomeados e bem descritos. Isso puxa para pôr mais coisas no núcleo. Resista a isso com os dados errados. Um agente ancorado numa cópia desatualizada dos dados do ERP dá respostas confiantes e erradas. Muitas vezes o melhor movimento é referenciar a fonte ao vivo, ou manter no núcleo um recorte pequeno e bem descrito. Onde a IA lê os dados faz agora parte de decidir onde vivem os dados.

Para saber mais

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (em inglês, consultado em 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-09-25)
• Neste curso: Virtualization, Federation, and Zero-Copy e Designing for Scale