Más que una base de datos

🌐 También en 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 1 de 10 del capítulo Arquitectura de datos de Salesforce, capítulo 3 del curso Data Architect. Cada módulo se sostiene por sí solo. Siguiente: Mira a la nave nodriza: los modelos de datos estándar

La pregunta que responde este módulo: ¿Qué hace distinto a Salesforce de una base de datos tradicional?

Si llevas un tiempo como administrador de Salesforce, ya sabes crear un objeto. Setup, Gestor de objetos, Nuevo objeto personalizado. Le das un nombre, agregas unos campos, armas un formato de página y diez minutos después los usuarios pueden trabajar con él.

Pero ¿qué pasó realmente cuando hiciste clic en Guardar?

Si vienes del mundo de las bases de datos, probablemente imaginas que Salesforce fue y creó una tabla nueva. No lo hizo. Y entender por qué es uno de los momentos en los que empiezas a pasar de pensar como un administrador o un desarrollador a pensar como un arquitecto.

Salesforce guarda datos, claro; debajo hay bases de datos. Pero Salesforce no es una base de datos con una pantalla bonita encima. Es una plataforma de aplicaciones basada en metadatos, y esa distinción da forma a casi todas las decisiones de este curso.

La plataforma tiene una forma

En el capítulo 2 construimos el modelo sin preocuparnos para nada por Salesforce. Fue a propósito: escuchamos los sustantivos, construimos el modelo conceptual, agregamos atributos, claves y relaciones, y solo entonces preguntamos cómo debería implementarlo Salesforce. Ahora tenemos que entender aquello sobre lo que lo estamos implementando.

Uso una frase sencilla para esto: la plataforma tiene una forma. Salesforce nos da objetos, campos, relaciones, seguridad, automatización, API, transacciones, informes y búsqueda, y todo está conectado. Cuando creo un objeto, no estoy creando solo un lugar donde poner filas. Estoy creando algo que participa en el modelo de seguridad, sobre lo que puede actuar la automatización, que exponen las API, que pueden usar los informes, con lo que otros objetos pueden relacionarse y de lo que dependerán los usuarios, las integraciones y, cada vez más, los agentes. Eso es mucho más que una tabla.

Los metadatos son el plano

Piensa en un edificio. Está el edificio en sí y está el plano que lo describe: dónde van los muros, dónde van las puertas, cómo se conectan las habitaciones. Salesforce funciona igual. La definición de un objeto son metadatos. La definición de un campo son metadatos. Una relación son metadatos. La mayor parte de lo que configuramos en Setup son metadatos, y la plataforma los lee en tiempo de ejecución para darle a nuestra organización su estructura y su comportamiento.

Salesforce describe el corazón de la plataforma como multiinquilino y basado en metadatos a la vez: cuando definimos un objeto o un campo, la definición se guarda como metadatos, no como una tabla o una columna física nueva para nuestra organización (Platform Multitenant Architecture (opens in a new tab), en inglés).

Cuando enseño esto, abro el capó. Salesforce no te crea una base de datos nueva cada vez que agregas un objeto. Agrega un registro a sus propias tablas: una tabla de objetos, una tabla de campos, una tabla de datos y tablas pivote para índices y relaciones, todo identificado por un identificador de organización que mantiene los datos de tu organización separados de los de todos los demás. Así que agregar un campo es solo agregar una entrada. Por eso puedes crear uno sobre la marcha, a la hora del almuerzo, en producción.

También explica algo con lo que la gente tropieza. Cuando escribes SELECT Id, Name, Special__c FROM Account, parece una sola tabla. Por debajo, estás leyendo el objeto estándar y su campo personalizado desde estructuras distintas, así que la plataforma está haciendo un join que tú nunca escribiste. Existen índices, pero no funcionan como el índice de una base de datos tradicional. No necesitas conocer las interioridades para el examen. Sí necesitas saber que lo que ves en el Gestor de objetos no es una imagen uno a uno de las tablas físicas, y que la abstracción es a la vez el poder de la plataforma y la razón por la que se comporta como se comporta.

Click to enlarge

Mira a la nave nodriza

Una de las cosas que digo en clase es que mires a la nave nodriza. Antes de inventar una forma complicada de hacer algo en Salesforce, mira cómo lo hace el propio Salesforce.

Toma la cuenta. Tú no la creaste; la creó Salesforce. Pero puedes agregarle campos, automatizar a su alrededor, cambiar sus formatos, exponerla a través de las API y relacionar otros objetos con ella. Los objetos personalizados funcionan con la misma maquinaria, por eso los objetos estándar y los personalizados se sienten tan parecidos cuando construimos sobre ellos. En Apex incluso comparten una clase base, el sObject.

Ese es el hábito sobre el que se construye este capítulo, y en el próximo módulo miramos con calma: los modelos de datos estándar que Salesforce ya construyó para ti.

No construimos al lado de Salesforce. Lo extendemos.

Tu API vino con el objeto

Crea una tabla en una base de datos tradicional y tienes una tabla. Si otra aplicación necesita trabajar con ella, alguien tiene más trabajo por hacer. Crea un objeto en Salesforce y la plataforma ya lo entiende a través de sus capas de aplicación e integración: usa los mismos metadatos para ofrecer sus API REST y SOAP, así que los registros del objeto se pueden crear, leer, actualizar y eliminar a través de ellas en cuanto el objeto existe (Platform Multitenant Architecture (opens in a new tab), en inglés).

No diseñé una API porque creé un objeto. La plataforma conoce el objeto, sus campos, sus tipos, sus relaciones y su seguridad. Esa es una razón por la que el desarrollo en Salesforce avanza tan rápido. También es por qué crear un objeto es una decisión más grande de lo que parece: estás enchufando una estructura a toda una plataforma de aplicaciones. Y también corta en el otro sentido. La gente que viene de SQL Server u Oracle a veces me pregunta cómo cargar datos directamente en la base de datos. No se puede. Todo entra por las API.

El edificio de departamentos

Ahora la palabra que oyes todo el tiempo: multiinquilino (multitenancy). Lo pienso como un edificio de departamentos.

Tienes tu departamento. Tus muebles son tuyos, y tu llave no debería abrir mi puerta. Pero compartimos el edificio: la electricidad, el agua, los ascensores, el vestíbulo. Tu organización se siente como tu propio entorno, con tus datos, tus objetos, tu automatización. Por debajo, Salesforce describe cada organización como un inquilino, y aísla los datos, los metadatos y la lógica de cada inquilino mientras la infraestructura y los servicios se comparten (Platform Multitenant Architecture (opens in a new tab), en inglés). Así es como puede dar a cada cliente una plataforma tan personalizable sin montar una infraestructura separada para cada uno.

Pero compartir el edificio tiene consecuencias. Si un inquilino compra un aire acondicionado enorme y pone el secador de pelo y el horno al mismo tiempo, salta el disyuntor y todo el piso se queda a oscuras.

No puedes adueñarte del ascensor

Quédate un minuto más en el edificio. Imagina que un residente anuncia: “Necesito el ascensor de ocho a doce. Nadie más puede usarlo”. Eso no funciona en un edificio compartido, y tampoco funciona en Salesforce. No se puede permitir que un inquilino consuma recursos compartidos sin límite y degrade la plataforma para todos los demás.

De ahí vienen los límites del gobernador (governor limits). Si has desarrollado en Salesforce, probablemente los conociste como una lista de números que memorizar. No quiero que los pienses así. Salesforce aplica límites a nivel de transacción y de organización para que la carga de trabajo de un inquilino no monopolice el cómputo compartido (Architecture Basics (opens in a new tab), en inglés). Esa es la arquitectura; cada límite individual es solo su implementación. Más adelante en el curso nos importarán límites concretos porque cambian un diseño. Por ahora, recuerda el edificio: tienes una libertad enorme para reformar tu departamento. Lo que no puedes es adueñarte del ascensor.

Los ID de Salesforce son parte de la abstracción

Cada registro de Salesforce tiene una identidad que la plataforma entiende, el ID de registro, y funciona en todas las capacidades: la interfaz, las API, los informes, la automatización.

En el capítulo 2 dijimos que una buena clave es única, inmutable, sin significado y nunca datos personales (PII). El ID de Salesforce cumple eso dentro de Salesforce. Pero no es lo mismo que una clave de negocio. Tu empresa puede seguir teniendo un número de cliente del ERP, un número de empleado o el número de pedido de un socio que tiene significado entre sistemas. No confundas “Salesforce sabe qué registro es este” con “la empresa sabe qué cosa del negocio es esta”. Son problemas de identificación distintos, y el segundo vuelve con la integración y los datos maestros.

Los objetos son más que almacenamiento

Este es el cambio que quiero que hagas antes del resto del capítulo. Un objeto no es solo un lugar donde guardar datos. Un campo no es solo una columna, y una relación no es solo una clave foránea. Uso las comparaciones con bases de datos cuando enseño, porque conectan con lo que la gente ya sabe. Pero si nos quedamos ahí, se nos escapa la arquitectura.

El objeto que elegimos decide qué capacidades vienen con él. El tipo de campo afecta la validación, la integración, la búsqueda, los informes y cómo leen los datos otros sistemas. La relación decide el ciclo de vida, la propiedad, el uso compartido y la eliminación. Dónde ponemos los datos afecta el almacenamiento, el rendimiento y la escala. Y como todo esto funciona sobre una plataforma compartida, una elección inofensiva con cien registros puede comportarse de forma muy distinta con cien millones. Tomaremos esas decisiones de una en una.

Más allá del examen: lo que cambia la IA. Durante años, los buenos nombres y descripciones ayudaron al siguiente administrador o desarrollador a entender lo que construimos. Ahora las máquinas también leen ese contexto. Un sistema de IA que trabaja con un campo llamado Flag2__c tiene el mismo problema que un desarrollador nuevo: ¿qué significa esto? Los metadatos ya no son decoración; son parte de cómo las máquinas entienden la aplicación.

Lo que decide aquí un arquitecto

• ¿Estoy diseñando para la plataforma en la que realmente estoy, o tratando Salesforce como una base de datos genérica?
• ¿Qué partes de mi diseño son conceptos de negocio y cuáles son decisiones de implementación de Salesforce?
• ¿Qué comportamiento de la plataforma viene con la estructura que estoy a punto de crear?
• ¿Qué límites son expresiones de la arquitectura compartida, y cuáles de ellos darán forma a este diseño?
• Si esta estructura será difícil de cambiar después, ¿la estoy tratando como una decisión de arquitectura?

En el capítulo 2 dijimos: no diseñes desde Setup. Ahora conoces otra razón. Hacer clic en Nuevo objeto personalizado no solo te da una tabla; conecta otra pieza de tu arquitectura a una plataforma multiinquilino basada en metadatos. Pero antes de decidir qué objeto crear, hay una pregunta más básica: ¿deberían vivir aquí estos datos? Eso viene a continuación.

Explora

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (en inglés), consultado el 2026-10-02, verificado de nuevo el 2026-10-12: las definiciones de objetos y campos se guardan como metadatos, no como tablas nuevas; tablas compartidas (MT_Objects, MT_Fields, MT_Data, MT_Indexes) identificadas por OrgID; los mismos metadatos ofrecen las API REST y SOAP.
• Salesforce Architects, Architecture Basics (opens in a new tab) (en inglés), consultado el 2026-10-02, verificado de nuevo el 2026-10-12: límites del gobernador y de ejecución para que el código y las transacciones “no monopolicen los recursos de cómputo compartidos”.