Onde esses dados vivem?

🌐 Também em 28 idiomas

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

Imagem gerada com IA

Traduzido por IA. Ainda não revisado 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 se sustenta 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 esses dados deveriam realmente viver: no núcleo, no Salesforce, referenciados onde já estão, ou arquivados?

Deixe-me fazer uma pergunta. Um requisito novo cai na sua mesa. Qual é a primeira coisa que você faz?

Se você é como a maioria de nós, abre o Setup e cria um objeto personalizado. Eu entendo. Em dez minutos você tem uma guia, um layout de página e uma visualização de lista. E eis o que digo a toda turma: no momento em que você cria aquele objeto novo, você já está pensando como arquiteto, quer tenha pretendido ou não. Porque cada objeto que você cria é um compromisso. Ocupa armazenamento. Acumula limites. Ganha um modelo de compartilhamento, quer você tenha projetado um ou não. Precisa de uma licença para qualquer pessoa que mexa nele. E, depois que pessoas e integrações dependem dele, boa sorte para tirá-lo.

Então a primeira decisão de arquitetura não é qual objeto. É onde esses dados deveriam viver? Acerte isso 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 roda: a plataforma multitenant orientada a metadados do módulo 1, onde vivem os objetos de Sales e Service do módulo 2, e todo objeto personalizado que você 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 (ele é próximo ao núcleo (near-core): gerenciado no núcleo, com os dados hospedados fora do núcleo; mais no capítulo 4). E aí há tudo o que a sua empresa roda e que nem é Salesforce: o ERP, o data warehouse, o sistema de pedidos, a plataforma do parceiro. Tudo isso está fora do núcleo (off core). O Salesforce consegue alcançar, mostrar e usar esses dados, mas a sua org não os armazena.

No núcleo, há dois tipos de objetos que de fato guardam os seus registros: os sObjects, padrão e personalizados (__c), e os big objects (__b). Fora do núcleo, você alcança os dados pelos objetos externos (__x) e pelas outras ferramentas de integração. Guarde esses sufixos do módulo 3 na cabeça; eles dizem onde um dado vive só pelo nome.

Penso nisso como um escritório. Algumas coisas ficam na sua mesa, onde você as usa todo dia. Outras você só precisa consultar no arquivo de outra pessoa. E outras vão para caixas no depósito dos fundos. Isso me dá três respostas.

1. No núcleo: vive na sua mesa

Os dados são criados, alterados e usados no Salesforce todos os dias: contas, casos, oportunidades, ordens de serviço. Guardá-los em sObjects é como guardá-los na frente do escritório. É para isso que existem os objetos padrão e personalizados, e você ganha tudo: layouts de página, compartilhamento, automação, relatórios, busca e, agora, os recursos de IA construídos sobre o modelo de dados.

Mas a sua mesa não é de graça. Dados no núcleo custam armazenamento, contado do jeito que o Salesforce conta, registro por registro, não coluna por coluna, e os documentos contam à parte, no armazenamento de arquivos. Vimos as duas coisas no módulo 2. Grandes volumes de fotos e digitalizações muitas vezes pertencem fora do núcleo, com o Salesforce guardando 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 pedidos), e esse sistema continua sendo a fonte da verdade. Os usuários precisam vê-los no Salesforce, talvez relacioná-los a um registro, mas o Salesforce não precisa de uma cópia própria. Você também vai ouvir isso ser chamado de dados virtuais: eles aparecem no Salesforce de forma virtual, sem nunca ficarem armazenados ali.

Isso são os objetos externos, pelo Salesforce Connect. Gosto de dizer que tem cara de pato e anda como pato, mas não é pato. Ele aparece como um sObject: você pode colocá-lo em layouts de página e listas relacionadas, e relacioná-lo aos seus próprios registros com relacionamentos de pesquisa externos e indiretos. Mas os dados não estão armazenados no núcleo. Toda vez que você mexe nele, ele faz uma chamada externa (callout). Abra um registro, carregue uma lista relacionada, rode um relatório, e o Salesforce vai lá perguntar ao outro sistema. Isso significa latência, e sua página só está tão disponível quanto o sistema por trás dela.

As pessoas reclamam do custo da licença, então faça a conta como faço em aula. 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 desenvolvedor de plantão quando quebrar. Muitas vezes a licença sai mais barata, e seus administradores conseguem configurá-la sem escrever uma linha de código. Onde ele não serve: dados que seus usuários editam o dia todo, ou sobre os quais fazem muitos relatórios.

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 deixa os usuários chegarem a ele a partir do Salesforce sem copiá-lo 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á controle 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 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 o depósito dos fundos

Histórico, trilhas de auditoria, transações antigas. Você precisa guardá-los, às vezes por anos, mas quase ninguém os abre. E este é o que as equipes adiam. Quando uma turma me conta que tem um objeto com 50 milhões de registros e pergunta por que arquivaria, devolvo a pergunta: se você não arquiva hoje, algum dia vai arquivar? Com 50 milhões hoje, você está a caminho de 100, 150, 200 milhões.

Há dois depósitos. Um fica no núcleo: os big objects. Pense neles como guardar dados na garagem. Você consegue guardar um número enorme de registros, mas não consegue colocá-los num layout de página, não há interface nem relatórios padrão, e você consulta 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 compartilhamento de registros, e a automação não roda neles. Já usei o Salesforce Connect dezenas de vezes e big objects só uma ou duas. Funcionam, mas são desajeitados, e já escrevi minha cota de gambiarras para chegar aos dados. Então meu conselho: faça um protótipo antes de sugerir, e planeje como as pessoas vão encontrar os dados antes de escolher.

O outro depósito fica fora do núcleo: um data warehouse ou um banco de dados em outro lugar (Designing for Scale). Muitas vezes esse é o depósito melhor, e ele não precisa ficar longe dos olhos. Dados arquivados fora do núcleo ainda podem aparecer em relatórios por ferramentas como o Tableau, e ainda podem ser alcançados a partir do Salesforce, pelo Salesforce Connect ou por outra forma de virtualizá-los, quando alguém precisa olhar para trás.

Deixe-me contar de um projeto em que acertamos isso desde o início. Um cliente varejista tinha mais de 1.200 unidades. Eles me disseram: “Só fazemos cem agendamentos por dia numa loja. Nada demais.” Aí fiz a conta: cem por dia, seis dias por semana (uns 305 dias por ano), em 1.200 unidades, dá mais de 36 milhões de agendamentos por ano. Depois mencionaram que cada visita criava dois agendamentos, um no balcão da frente e um para os fundos da loja: mais de 73 milhões de registros por ano. Depois quiseram cinco anos de histórico: mais de 360 milhões de registros, antes de qualquer crescimento. Ainda nem tínhamos entrado em produção, e eu já via o trem indo direto para a estação dos grandes volumes de dados. Então o arquivo foi construído antes de coletarmos um único agendamento: os agendamentos mais antigos iam para big objects, e a tela de busca mostrava os agendamentos atuais com os arquivados logo abaixo. Anos depois, continua rodando 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 retira eletrodomésticos e eletrônicos nos centros de distribuição de grandes varejistas, e depois os entrega e instala na casa dos clientes. Quatro tipos de dados dela, três respostas:

Dados	Onde vivem	Por quê
As entregas, equipes e agendamentos de hoje	No núcleo	Despachantes e equipes trabalham neles o dia todo
Os detalhes do pedido do varejista	Referenciados (ou uma cópia enxuta no núcleo)	O sistema do varejista é 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
Fotos 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, ela vai para o Histórico de entregas (Delivery History), um big object: ainda no núcleo, mas lá no depósito. O pedido do parceiro aparece como um objeto externo, __x: o Salesforce relaciona a entrega a ele, mas os dados ficam no sistema do varejista. E as fotos vivem totalmente fora do núcleo, com um link a partir da entrega. Um modelo, três casas.

Click to enlarge

Toda org real tem os três. As que se complicam colocaram tudo no núcleo, porque criar um objeto era o botão padrão.

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 virar 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 a conta agora (registros 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”. Recursos de IA e agentes funcionam melhor com dados que a plataforma entende: dados em objetos padrão e personalizados, bem nomeados e bem descritos. Isso puxa para colocar 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 agora faz parte de decidir onde os dados vivem.

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