Cada estrutura é um compromisso

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

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

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

Eis uma pergunta que faço em todas as turmas. Se alguém diz «eu trabalho com Salesforce», qual é o nome de API do objeto de produto?

É Product2. É o meu primeiro teste decisivo. A dada altura, a Salesforce construiu o objeto de produto, percebeu que não estava a funcionar e teve de o deixar para trás. Não dava simplesmente para o tirar, por isso acrescentaram o Product2. Até a Salesforce convive com as suas estruturas antigas.

A Salesforce também deixou espaço para crescer. Os 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. Por isso a Salesforce pode continuar a acrescentar 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 acrescenta é um compromisso. Ocupa armazenamento. Acumula limites. Ganha um modelo de partilha, quer tenha projetado um ou não. Precisa de uma licença para cada pessoa que lhe toca. E agora a IA também o lê, por isso o nome que lhe dá e a forma como 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 dá-lhe seis lugares para guardar dados. Ponho-os todos num diapositivo, porque o primeiro trabalho é saber que existem todos:

Estrutura	Para que serve	O porém
Objetos padrão	O modelo da própria Salesforce: Conta, Contacto, Oportunidade, Caso, Ativo e o resto	Use-os para o que foram feitos, ou lutam contra si
Objetos personalizados	Os dados do seu próprio negócio	Fáceis de criar, difíceis de retirar
Objetos externos	Dados que vivem noutro sistema, apresentados no Salesforce	Cada acesso é uma chamada externa (callout)
Big objects	Volumes enormes que precisa de guardar mas raramente abre	Sem interface nem relatórios padrão; consulta-os pelo índice
Ficheiros	Documentos, fotografias e outros conteúdos	O armazenamento de ficheiros sobe depressa
Anexos	A forma antiga de guardar ficheiros	Legado: use Ficheiros

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

O percurso deste capítulo

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

1. A plataforma de dados Salesforce: mais do que uma base de dados. O que torna o Salesforce diferente, e porque é 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, ficheiros, armazenamento e contas pessoais.
3. Construa o seu: objetos personalizados. O que o ecrã New Custom Object (Novo objeto personalizado) decide, os campos que não criou, e como ler qualquer nome de API: padrão, personalizado ou de pacote gerido.
4. Onde vivem estes dados? 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, as contas pessoais, e as licenças que decidem o que as pessoas podem usar.
6. Os campos também são arquitetura. Tipo de campo a tipo de campo, os comportamentos que surpreendem as pessoas, e porque é que cada campo ganha uma descrição.
7. As relações têm consequências. Relação de pesquisa ou mestre-detalhe, 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 registo, a tabela de partilha onde a propriedade se torna acesso, e o que acontece a um registo ao longo da vida.
9. Manter os dados consistentes. A escada da consistência: cada camada tem um custo, e nunca se «corrige» o histórico para satisfazer uma regra nova.
10. Desenhe 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 a 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 vive cada tipo de dado, no núcleo, referenciado ou arquivado, antes de escolher uma estrutura.
• Que estrutura o guarda, sabendo de que abdica cada uma.
• Como se relacionam os objetos, quem é dono dos registos, e o que isso significa para o acesso e a escala.
• De que licenças depende o modelo, verificado antes de projetar os objetos, não depois.
• Como os dados se mantêm 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 nessa 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: Entender os dados empresariais