Cada estrutura é um compromisso

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

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Capítulo 3 de Data Architect, Parte 1: Tornando-se arquiteto de dados. Anterior: Modelar dados pelo significado.

Eis uma pergunta que faço em toda turma. Se alguém diz “eu trabalho com Salesforce”, qual é o nome de API do objeto de produto?

É Product2. É meu primeiro teste decisivo. Em algum momento, a Salesforce construiu o objeto de produto, percebeu que não estava funcionando e teve de deixá-lo para trás. Não dava simplesmente para tirá-lo, então acrescentaram o Product2. Até a Salesforce convive com suas estruturas antigas.

A Salesforce também deixou espaço para crescer. Seus objetos padrão não levam prefixo nem sufixo, e nós, as pessoas que personalizam as orgs, nunca podemos ocupar esse espaço. Então a Salesforce pode continuar acrescentando objetos sem nunca colidir com nada que construímos.

A lição está aí: criar um objeto leva dez minutos. Conviver com ele leva anos. Cada objeto e cada campo que você acrescenta é 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 cada pessoa que mexe nele. E agora a IA também o lê, então o nome que você dá e como você o descreve decidem o que um agente entende sobre os seus dados. Acrescentar é fácil. Tirar é difícil.

Este capítulo transforma os blocos de construção do Salesforce em decisões.

Imagem gerada com IA.

As estruturas num relance

O Salesforce lhe dá seis lugares para guardar dados. Coloco todos num slide, porque o primeiro trabalho é saber que todos existem:

Estrutura	Para que serve	O porém
Objetos padrão	O modelo da própria Salesforce: Conta, Contato, Oportunidade, Caso, Ativo e o resto	Use-os para o que foram feitos, ou eles brigam com você
Objetos personalizados	Os dados do seu próprio negócio	Fáceis de criar, difíceis de aposentar
Objetos externos	Dados que vivem em outro sistema, exibidos no Salesforce	Cada acesso é uma chamada externa (callout)
Big objects	Volumes enormes que você precisa guardar mas raramente abre	Sem interface nem relatórios padrão; você consulta pelo índice
Arquivos	Documentos, fotos e outros conteúdos	O armazenamento de arquivos sobe rápido
Anexos	A forma antiga de guardar arquivos	Legado: use Arquivos

Escolher uma delas, porém, é só parte da história. Antes da estrutura vem a pergunta de onde os dados devem viver, para começo de conversa: no núcleo, referenciados onde já estão, ou arquivados.

O caminho por este capítulo

Este capítulo é grande, então vem em dez partes. Cada uma se sustenta sozinha. No capítulo 2 decidimos o que o modelo deve ser; aqui decidimos como ele deve viver no Salesforce.

1. A plataforma de dados Salesforce: mais que um banco de dados. O que torna o Salesforce diferente, e por que a plataforma tem uma forma.
2. Olhe para a nave-mãe: os modelos de dados padrão. Os modelos de vendas (Sales) e de serviço (Service) que a Salesforce já construiu, arquivos, armazenamento e contas pessoais.
3. Construa o seu: objetos personalizados. O que a tela New Custom Object (Novo objeto personalizado) decide, os campos que você não criou, e como ler qualquer nome de API: padrão, personalizado ou de pacote gerenciado.
4. Onde esses dados vivem? No núcleo, referenciados ou arquivados, decidido antes de criar qualquer objeto.
5. Escolha o objeto certo. O teste do encaixe limpo, a bagagem que os objetos padrão trazem, contas pessoais, e as licenças que decidem o que as pessoas podem usar.
6. Campos também são arquitetura. Tipo de campo por tipo de campo, os comportamentos que surpreendem as pessoas, e por que todo campo ganha uma descrição.
7. Relacionamentos têm consequências. Relacionamento de pesquisa ou mestre-detalhes, três níveis de profundidade e dois pais de largura, o objeto de junção lógico e o objeto de junção do Salesforce (Salesforce Junction Object), e os limites que mordem.
8. Propriedade e ciclo de vida. Quem é dono de um registro, a tabela de compartilhamento onde a propriedade vira acesso, e o que acontece com um registro ao longo da vida.
9. Mantendo os dados consistentes. A escada da consistência: cada camada tem um custo, e você nunca “conserta” o histórico para satisfazer uma regra nova.
10. Projete o modelo físico Salesforce. Um recorte da Steve Trucking, do modelo lógico ao Salesforce, construído passo a passo, com o raciocínio.

Quando terminar, teste-se com o guia de estudo do capítulo: uma lista para o exame, os hábitos que vão além dele, as palavras para conhecer e algumas perguntas.

O que um arquiteto decide aqui

• O que o Salesforce já modela, antes de inventar qualquer coisa: olhe para a nave-mãe.
• Onde cada tipo de dado vive, no núcleo, referenciado ou arquivado, antes de escolher uma estrutura.
• Qual estrutura o guarda, sabendo do que cada uma abre mão.
• Como os objetos se relacionam, quem é dono dos registros, e o que isso significa para o acesso e a escala.
• De quais licenças o modelo depende, verificado antes de projetar os objetos, não depois.
• Como os dados continuam consistentes, e quanto custa cada camada de consistência.

Além do exame: construir com ajuda de IA pode criar objetos e campos em minutos. Quando acrescentar é quase de graça, “cada estrutura é um compromisso” importa mais, não menos. Cada módulo termina com o que a IA muda naquela decisão.

Para saber mais

• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (em inglês)
• Standard User Licenses (opens in a new tab), Salesforce Help (em inglês)

Próximo: Entendendo os dados corporativos