Mais que um banco de dados

🌐 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 1 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Próximo: Olhe para a nave-mãe: os modelos de dados padrão

A pergunta que este módulo responde: O que torna o Salesforce diferente de um banco de dados tradicional?

Se você é administrador Salesforce há algum tempo, já sabe criar um objeto. Setup, Gerenciador de objetos, Novo objeto personalizado. Dê um nome, acrescente alguns campos, monte um layout de página, e dez minutos depois os usuários conseguem trabalhar com ele.

Mas o que realmente aconteceu quando você clicou em Salvar?

Se você vem de banco de dados, provavelmente imagina que o Salesforce foi lá e criou uma tabela nova. Não criou. E entender por quê é um dos pontos em que você começa a passar de pensar como administrador ou desenvolvedor para pensar como arquiteto.

O Salesforce armazena dados, claro; há bancos de dados por baixo. Mas o Salesforce não é um banco de dados com uma tela bonita por cima. Ele é uma plataforma de aplicações orientada por metadados, e essa distinção molda quase todas as decisões deste curso.

A plataforma tem uma forma

No capítulo 2 construímos o modelo sem nos preocupar nem um pouco com o Salesforce. Foi de propósito: ouvimos os substantivos, construímos o modelo conceitual, acrescentamos atributos, chaves e relacionamentos, e só então perguntamos como o Salesforce deveria implementá-lo. Agora precisamos entender a coisa sobre a qual o estamos implementando.

Uso uma frase simples para isso: a plataforma tem uma forma. O Salesforce nos dá objetos, campos, relacionamentos, segurança, automação, APIs, transações, relatórios e busca, e tudo isso está conectado. Quando crio um objeto, não estou só criando um lugar para colocar linhas. Estou criando algo que participa do modelo de segurança, sobre o qual a automação pode agir, que as APIs expõem, que os relatórios podem usar, com que outros objetos podem se relacionar, e de que usuários, integrações e, cada vez mais, agentes vão depender. Isso é muito mais que uma tabela.

Os metadados são a planta

Pense num edifício. Há o edifício em si, e há a planta que o descreve: onde ficam as paredes, onde vão as portas, como os cômodos se conectam. O Salesforce funciona do mesmo jeito. A definição de um objeto é metadado. A definição de um campo é metadado. Um relacionamento é metadado. A maior parte do que configuramos no Setup é metadado, e a plataforma o lê em tempo de execução para dar à nossa org sua estrutura e seu comportamento.

A Salesforce descreve o coração da plataforma como multitenant e orientado por metadados: quando definimos um objeto ou um campo, a definição é armazenada como metadado, não como uma nova tabela ou coluna física para a nossa org (Platform Multitenant Architecture (opens in a new tab), em inglês).

Quando ensino isto, abro o capô. O Salesforce não cria um banco de dados novo para você cada vez que você acrescenta um objeto. Ele acrescenta um registro às suas próprias tabelas: uma tabela de objetos, uma tabela de campos, uma tabela de dados, e tabelas auxiliares para índices e relacionamentos, tudo com a chave de um identificador de org que mantém os dados da sua org separados dos de todos os outros. Então acrescentar um campo é só acrescentar uma entrada. É por isso que você consegue criar um na hora, na hora do almoço, em produção.

Isso também explica algo em que as pessoas tropeçam. Quando você escreve SELECT Id, Name, Special__c FROM Account, parece uma tabela só. Por baixo, você está lendo o objeto padrão e o seu campo personalizado de estruturas diferentes, então a plataforma está fazendo um join que você nunca escreveu. Índices existem, mas não funcionam como o índice de um banco de dados tradicional. Você não precisa conhecer os detalhes internos para o exame. Precisa saber que o que você vê no Gerenciador de objetos não é um retrato um-para-um de tabelas físicas, e que a abstração é ao mesmo tempo o poder da plataforma e o motivo pelo qual ela se comporta como se comporta.

Click to enlarge

Olhe para a nave-mãe

Uma das coisas que digo às pessoas em aula é para olhar para a nave-mãe. Antes de inventar algum jeito complicado de fazer algo no Salesforce, veja como o próprio Salesforce faz.

Pegue a Conta. Você não a criou; a Salesforce criou. Mas você pode acrescentar campos a ela, automatizar em torno dela, mudar seus layouts, expô-la pelas APIs e relacionar outros objetos a ela. Os objetos personalizados rodam na mesma maquinaria, e é por isso que objetos padrão e personalizados parecem tão parecidos quando construímos sobre eles. No Apex, eles até compartilham uma classe base, o sObject.

Esse é o hábito sobre o qual este capítulo se constrói, e no próximo módulo olhamos de verdade: para os modelos de dados padrão que a Salesforce já construiu para você.

Não estamos construindo ao lado do Salesforce. Estamos estendendo-o.

Sua API veio com o objeto

Crie uma tabela num banco de dados tradicional e você tem uma tabela. Se outra aplicação precisa trabalhar com ela, alguém tem mais trabalho pela frente. Crie um objeto no Salesforce, e a plataforma já o entende pelas suas camadas de aplicação e de integração: ela usa os mesmos metadados para oferecer suas APIs REST e SOAP, então os registros do objeto podem ser criados, lidos, atualizados e excluídos por meio delas assim que o objeto existe (Platform Multitenant Architecture (opens in a new tab), em inglês).

Não projetei uma API porque criei um objeto. A plataforma conhece o objeto, seus campos, os tipos deles, seus relacionamentos e sua segurança. Esse é um dos motivos pelos quais o desenvolvimento em Salesforce anda tão rápido. É também por isso que criar um objeto é uma decisão maior do que parece: você está ligando uma estrutura a uma plataforma de aplicações inteira. E vale para o outro lado também. Pessoas que vêm de SQL Server ou Oracle às vezes me perguntam como carregar dados direto no banco. Não dá. Tudo entra pelas APIs.

O prédio de apartamentos

Agora a palavra que você ouve o tempo todo: multitenancy, ou multilocação. Penso nisso como um prédio de apartamentos.

Você tem o seu apartamento. Seus móveis são seus, e a sua chave não deveria abrir a minha porta. Mas dividimos o prédio: a energia, a água, os elevadores, o saguão. Sua org parece um ambiente só seu, com seus dados, seus objetos, sua automação. Por baixo, a Salesforce descreve cada org como um inquilino (tenant), isolando os dados, os metadados e a lógica de cada inquilino enquanto a infraestrutura e os serviços são compartilhados (Platform Multitenant Architecture (opens in a new tab), em inglês). É assim que ela consegue dar a cada cliente uma plataforma tão personalizável sem rodar uma pilha separada para cada um.

Mas dividir o prédio tem consequências. Se um inquilino compra um ar-condicionado enorme e liga o secador de cabelo e o forno ao mesmo tempo, ele derruba o disjuntor, e o andar inteiro fica no escuro.

Você não pode tomar conta do elevador

Fique no prédio mais um minuto. Imagine que um morador anuncia: “Preciso do elevador das oito ao meio-dia. Ninguém mais pode usar.” Isso não funciona num prédio compartilhado, e também não funciona no Salesforce. Não se pode permitir que um inquilino consuma recursos compartilhados sem limite e degrade a plataforma para todos os outros.

É daí que vêm os limites do governador (governor limits). Se você já desenvolveu no Salesforce, provavelmente os conheceu como uma lista de números para decorar. Não quero que você pense neles assim. A Salesforce aplica limites no nível da transação e da org para que a carga de trabalho de um inquilino não monopolize a computação compartilhada (Architecture Basics (opens in a new tab), em inglês). Essa é a arquitetura; cada limite individual é só a implementação dela. Mais adiante no curso vamos nos importar com limites específicos porque eles mudam um design. Por enquanto, lembre-se do prédio: você tem uma liberdade enorme para reformar o seu apartamento. Você não pode tomar conta do elevador.

Os IDs do Salesforce fazem parte da abstração

Todo registro Salesforce tem uma identificação que a plataforma entende, o ID de registro, e ela funciona em todas as capacidades: a interface, as APIs, os relatórios, a automação.

No capítulo 2 dissemos que uma boa chave é única, imutável, sem significado e nunca dado pessoal. O ID do Salesforce atende a isso para o Salesforce. Mas ele não é a mesma coisa que uma chave de negócio. Sua empresa ainda pode ter um número de cliente do ERP, um número de funcionário ou o número de pedido de um parceiro que significa algo entre sistemas. Não confunda “o Salesforce sabe qual registro é este” com “a empresa sabe qual coisa de negócio é esta”. São problemas de identificação diferentes, e o segundo volta na integração e nos dados mestres.

Objetos são mais que armazenamento

Eis a virada que quero que você faça antes do resto deste capítulo. Um objeto não é só um lugar para guardar dados. Um campo não é só uma coluna, e um relacionamento não é só uma chave estrangeira. Uso as comparações com banco de dados quando ensino, porque elas se ligam ao que as pessoas já sabem. Mas se pararmos aí, perdemos a arquitetura.

O objeto que escolhemos decide quais capacidades vêm com ele. O tipo de campo afeta validação, integração, busca, relatórios e como outros sistemas leem os dados. O relacionamento decide ciclo de vida, propriedade, compartilhamento e exclusão. Onde colocamos os dados afeta armazenamento, desempenho e escala. E, como tudo isso roda numa plataforma compartilhada, uma escolha inofensiva com cem registros pode se comportar de forma muito diferente com cem milhões. Vamos tomar essas decisões uma de cada vez.

Além do exame: o que a IA muda. Durante anos, bons nomes e boas descrições ajudaram o próximo administrador ou desenvolvedor a entender o que construímos. Agora as máquinas também leem esse contexto. Um sistema de IA trabalhando com um campo chamado Flag2__c tem o mesmo problema que um desenvolvedor novo: o que essa coisa significa? Os metadados não são mais decoração; fazem parte de como as máquinas entendem a aplicação.

O que um arquiteto decide aqui

• Estou projetando para a plataforma em que realmente estou, ou tratando o Salesforce como um banco de dados genérico?
• Quais partes do meu design são conceitos de negócio, e quais são escolhas de implementação do Salesforce?
• Que comportamento da plataforma vem junto com a estrutura que estou prestes a criar?
• Quais limites são expressões da arquitetura compartilhada, e quais deles vão moldar este design?
• Se esta estrutura vai ser difícil de mudar depois, estou tratando-a como uma decisão de arquitetura?

No capítulo 2 dissemos: não projete a partir do Setup. Agora você conhece outro motivo. Clicar em Novo objeto personalizado não lhe dá só uma tabela; conecta mais uma peça da sua arquitetura a uma plataforma multitenant orientada por metadados. Mas antes de decidir que objeto criar, há uma pergunta mais básica: esses dados deveriam sequer viver aqui? Esse é o próximo módulo.

Para saber mais

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (em inglês, consultado em 2026-10-02; reconsultado em 2026-10-12): as definições de objetos e campos são guardadas como metadados, não como tabelas novas; tabelas compartilhadas (MT_Objects, MT_Fields, MT_Data, MT_Indexes) indexadas pelo OrgID; os mesmos metadados oferecem as APIs REST e SOAP.
• Salesforce Architects, Architecture Basics (opens in a new tab) (em inglês, consultado em 2026-10-02; reconsultado em 2026-10-12): limites do governador e de execução para que o código e as transações “não monopolizem recursos de computação compartilhados”.