Ir al contenido
SteveTechArcSteveTechArc Courses

Dentro del motor de Salesforce

También en 2 idiomas

English · Español (México)

A straight-six car engine on a workshop stand with its cover off and one side cut away, showing the six pistons and the crankshaft inside.
Imagen generada con IA

Módulo 1 de 5 del capítulo Arquitectura de consultas y recuperación, capítulo 8 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: el capítulo anterior, Diseñar para la escala · Siguiente: Cómo encuentra Salesforce tus datos

La pregunta que responde este módulo: ¿por qué Salesforce no funciona como Oracle o SQL Server?

En clase, aquí es donde hago una pausa, y cuando todos vuelven digo: vamos a abrir el capó. Vamos a abrir el motor de Salesforce y mirar las piezas que lo hacen funcionar. Es la parte más técnica del curso. La mayor parte no entra en el examen, y te avisaré cuando algo sí entre. Pero responde a una pregunta que tarde o temprano me hace toda la gente de bases de datos: ¿por qué Salesforce no funciona sin más como Oracle o SQL Server?

En el capítulo 7 te hablé de aquella sala de Dreamforce llena de administradores de bases de datos que preguntaban exactamente eso. Salesforce les responde en su propia guía: “si aplicas técnicas tradicionales de ajuste del rendimiento basadas en los datos y el esquema de tu organización, puede que no veas el efecto que esperas en las estructuras de datos reales subyacentes”, y “tampoco puedes optimizar el SQL que hay debajo de muchas operaciones de la aplicación, porque lo genera el sistema” (Multitenancy and Metadata Overview (se abre en una pestaña nueva), Winter ‘27). La razón está debajo de la plataforma. Conduces Salesforce todos los días: creas objetos, añades campos, escribes consultas. Hoy miramos el motor. No necesitas saber construirlo. Necesitas entenderlo lo bastante bien para diseñar el coche.

Un edificio, muchos inquilinos

Sección titulada «Un edificio, muchos inquilinos »

Ya conoces esta idea, del capítulo 3: Salesforce es multiinquilino. Piensa en un edificio de apartamentos. Cada empresa tiene su propio apartamento, con sus propios muebles y su propia llave, y tu llave no abre la puerta de nadie más. Pero todos comparten el edificio: la electricidad, el agua, los ascensores.

En Salesforce, la llave tiene nombre: el ID de la organización (org ID). La organización de cada empresa tiene uno, y cada registro que Salesforce guarda para esa organización lo lleva. Así es como muchas empresas pueden compartir un edificio con seguridad. La guía Well-Architected de Salesforce lo dice claramente: “Un núcleo compartido y basado en metadatos divide los datos y metadatos de cada organización por ID de organización, de modo que una organización no puede llegar a los registros de otra aunque ambas se ejecuten en una infraestructura compartida. El núcleo impone la separación en cada consulta, no mediante una configuración que tengas que mantener” (Trust (se abre en una pestaña nueva)). No cierras con llave la puerta de tu apartamento cada noche; el edificio lo hace por ti, en cada solicitud.

Eso no significa que la seguridad deje de ser tu trabajo. La misma guía la divide en dos: “Salesforce es responsable de la seguridad de la plataforma, incluidas la infraestructura, los parches y las certificaciones de cumplimiento. Tú eres responsable de la seguridad en la plataforma, incluidas la configuración, los controles de acceso, el código personalizado y el gobierno de datos” (misma fuente). El edificio mantiene separados a los inquilinos. Quién recibe la llave de qué habitaciones dentro de tu apartamento lo diseñas tú, y ese es el modelo de uso compartido que volverás a ver en el capítulo 12.

Y un edificio compartido necesita normas. Si todos los apartamentos encienden a la vez un aire acondicionado potente, un secador de pelo y el horno, salta el disyuntor y toda la planta se queda sin luz. Por eso Salesforce tiene límites del regulador (governor limits): impiden que un solo inquilino se lleve la energía que necesitan todos los demás.

Salesforce describe la plataforma como dos cosas a la vez (Platform Multitenant Architecture (se abre en una pestaña nueva)):

  • Multiinquilino: “Aísla y atiende de forma simultánea los distintos requisitos de muchos inquilinos.”
  • Basada en metadatos: “Permite a cada inquilino personalizar de forma fácil y rápida sus aplicaciones y experiencias de usuario mediante metadatos, datos que describen elementos como la interfaz de usuario (UI) y la lógica de negocio.”

La segunda es donde el motor empieza a parecer distinto de la base de datos que conoces.

Un núcleo, los metadatos de tu organización, una base de datos compartida Cuatro capas, de arriba abajo. Un usuario de Steve Trucking hace una solicitud a la organización de Steve Trucking, su propia vista del esquema montada en tiempo de ejecución, que muestra juntas piezas estándar (Account, Work Order, Flow) y propias (Retail Partner, Delivery Reference). Debajo, el núcleo, el entorno de ejecución de la aplicación, que materializa cada organización en tiempo de ejecución: la lógica central (los objetos y capacidades estándar) más los metadatos de Steve Trucking (sus objetos, campos y configuración) se unen en el procesamiento de la derecha, que ejecuta la solicitud sobre sus filas y monta la organización. Abajo del todo, la base de datos compartida, una por instancia de Salesforce y compartida por sus organizaciones, con un esquema y tres tipos de tablas: tablas de metadatos estándar, que lee la lógica central; tablas de datos compartidas en el centro, donde el procesamiento lee y escribe solo sus propias filas, y cada fila lleva el ID de su organización, con las filas de Steve Trucking entre las de otras empresas; y tablas de metadatos de clientes, también por organización, de las que el núcleo toma solo las filas de Steve Trucking. Un usuario de Steve Trucking hace una solicitud La organización de Steve Trucking su propia vista del esquema, montada en tiempo de ejecución Cuenta Orden de trabajo Socio minorista Referencia de entrega Flow El núcleo, el entorno de ejecución materializa cada organización en tiempo de ejecución Lógica central objetos y capacidades estándar Cuenta Contacto Caso Orden de trabajo Flow Informes Seguridad API Metadatos de Steve Trucking sus objetos, campos y configuración Socio minorista Referencia de entrega formatos flujos uso compartido Procesamiento ejecuta la solicitud sobre sus filas lógica de negocio consultas guardados API + Base de datos compartida una por instancia de Salesforce, compartida por sus organizaciones un esquema, tres tipos de tablas TABLAS DE METADATOS ESTÁNDAR Cuenta Contacto Caso Orden de trabajo Flow, informes, seguridad TABLAS DE METADATOS DE CLIENTES org 1 Socio minorista: un objeto org 2 un campo personalizado org 1 Referencia de entrega: un campo org 3 un objeto personalizado org 1 sus flujos y uso compartido TABLAS DE DATOS COMPARTIDAS org 1 Steve Trucking: una orden de trabajo org 2 otra empresa: un registro org 3 otra empresa: un registro org 1 Steve Trucking: una cuenta org 4 otra empresa: un registro solicitud monta juntos lee lee sus filas escribe sus filas solo sus filas CÓMO LEERLO estándar de Salesforce: igual para todos las filas de Steve Trucking las filas de otras empresas lo que ve su usuario © 2026 Twinshark LLC · stevetecharc.com
Clic para ampliar

Un núcleo, los metadatos de tu organización, una base de datos compartida.

Sin tablas nuevas, solo metadatos

Sección titulada «Sin tablas nuevas, solo metadatos »

En Oracle o SQL Server, cuando necesitas un nuevo tipo de registro, un administrador de bases de datos crea una tabla. ¿Un campo nuevo? Se altera la tabla y se añade una columna. En un sistema con mucha actividad, eso puede significar bloquear la tabla o programar una parada.

Salesforce no hace eso. En sus propias palabras: “Cuando creas un nuevo objeto de aplicación o escribes código con Salesforce Platform, la plataforma no crea una tabla real en una base de datos ni compila ningún código. En su lugar, la plataforma simplemente almacena unos metadatos que luego puede usar en tiempo de ejecución para materializar de forma dinámica componentes virtuales de la aplicación.”

Así que tu objeto Work Order no es una tabla. Es la descripción de una tabla, guardada como filas de metadatos. Cuando llega una solicitud, el núcleo (kernel) de la plataforma, su entorno de ejecución de la aplicación, lee esos metadatos y tus datos de una base de datos compartida y monta sobre la marcha la vista de tu organización. Salesforce dice que cada instancia se ejecuta sobre “una única base de datos multiinquilino compartida con un único esquema” y “un núcleo multiinquilino (entorno de ejecución de la aplicación) que lee metadatos y datos para ofrecer de forma dinámica, en tiempo de ejecución, aplicaciones, lógica de negocio y API específicas de cada inquilino a sus usuarios”.

Por eso puedes añadir un campo a la hora de comer en producción y nadie se da cuenta. No cambió nada físico. Se añadió una fila de metadatos.

Añadir un campo es añadir una fila Un administrador de Steve Trucking añade un campo, Truck Number en Work Order, a la hora de comer en producción. Una flecha etiquetada añade una fila apunta a la base de datos compartida, una por instancia de Salesforce y compartida por sus organizaciones, con un esquema y tres tipos de tablas: tablas de metadatos estándar, tablas de metadatos de clientes y tablas de datos compartidas. En las tablas de metadatos de clientes aparece una fila nueva, resaltada: organización 1, Truck Number, un campo de Work Order. Nada más cambia: ni tabla nueva ni columna nueva. Debajo, atenuada para contrastar, una base de datos tradicional: allí un campo nuevo es una columna nueva, Truck Number, añadida a la tabla Work Order, que queda bloqueada mientras cambia, y en un sistema con mucha actividad eso puede significar una parada. Un administrador de Steve Trucking añade un campo: Truck Number en Work Order, a la hora de comer, en producción Base de datos compartida una por instancia de Salesforce, compartida por sus organizaciones un esquema, tres tipos de tablas TABLAS DE METADATOS ESTÁNDAR Cuenta Contacto Caso Orden de trabajo Flow, informes, seguridad TABLAS DE METADATOS DE CLIENTES org 1 Socio minorista: un objeto org 2 un campo personalizado org 1 Referencia de entrega: un campo org 3 un objeto personalizado org 1 sus flujos y uso compartido org 1 Truck Number: un campo de Work Order TABLAS DE DATOS COMPARTIDAS org 1 Steve Trucking: una orden de trabajo org 2 otra empresa: un registro org 3 otra empresa: un registro org 1 Steve Trucking: una cuenta org 4 otra empresa: un registro En una base de datos tradicional un campo nuevo es una columna nueva: la tabla se bloquea mientras cambia, y en un sistema con mucha actividad eso puede significar una parada Work Order Status Date Truck Number añade una fila CÓMO LEERLO estándar de Salesforce: igual para todos las filas de Steve Trucking las filas de otras empresas la fila nueva: ni tabla nueva ni columna nueva © 2026 Twinshark LLC · stevetecharc.com
Clic para ampliar

Añadir un campo es añadir una fila.

Unas pocas tablas compartidas lo guardan todo

Sección titulada «Unas pocas tablas compartidas lo guardan todo »

Ahora miremos las propias tablas. Hay sorprendentemente pocas, y todos los inquilinos las comparten. La guía actual de Salesforce lo resume en una frase: “Salesforce almacena los datos de aplicación de todas las tablas virtuales en unas pocas tablas grandes de base de datos, que están particionadas por inquilino y sirven de almacenamiento heap”, y las gestiona “mediante un conjunto de tablas de metadatos, de datos y dinámicas (pivot)” (Multitenancy and Metadata Overview (se abre en una pestaña nueva), Winter ‘27). El documento de arquitectura de Salesforce les pone nombre, y este es el diseño que describe.

Cada fila lleva un ID de organización. Salesforce: “cada registro específico de una organización en las tablas compartidas de la base de datos tiene un OrgID. Cuando el núcleo accede a la base de datos, usa este identificador único para garantizar que las actividades de cada organización sean privadas.” Los datos están en tablas compartidas, pero se mantienen separados, fila a fila.

Las tablas de metadatos (Salesforce las llama Universal Data Dictionary):

  • MT_Objects tiene una fila por cada objeto: su ID, el ID de tu organización y el nombre del objeto. Tu objeto Work Order es una fila aquí.
  • MT_Fields tiene una fila por cada campo: a qué objeto pertenece, su tipo de datos, si está indexado y su posición.

La tabla de datos, MT_Data, guarda los propios registros, de todos los objetos, de todas las organizaciones. Cada fila tiene un ID único, el ID de la organización, el ID del objeto, un Name y luego una larga fila de columnas de uso general llamadas Value0 … ValueN, que Salesforce llama columnas flexibles (flex columns) o ranuras (slots). Cada ranura es una cadena de longitud variable, así que puede guardar texto, un número o una fecha: la plataforma los almacena en un formato estándar y los convierte cuando se leen o escriben tus datos. El texto largo, de hasta 32.000 caracteres, se guarda aparte en MT_Clob.

Esto es lo que significa en la práctica. En la organización de Steve Trucking, Truck_Number__c de Work Order podría vivir en la ranura Value7. En la organización de otra empresa, en la misma tabla, Value7 podría guardar Favorite_Ice_Cream__c de un objeto completamente distinto. Salesforce lo dice claramente: “no hay dos campos del mismo objeto que puedan asignarse a la misma ranura de MT_Data para su almacenamiento; sin embargo, una sola ranura puede gestionar la información de varios campos, siempre que cada campo proceda de un objeto distinto.” Tus metadatos le dicen a la plataforma qué significa Value7 para ti.

Unas pocas tablas compartidas lo guardan todo Paso 1: las tablas compartidas. A la izquierda, los metadatos: MT_Objects, una fila por objeto (ObjID, OrgID, ObjName), tiene muchas filas en MT_Fields, una fila por campo (FieldID, OrgID, ObjID, FieldName, tipo de datos, IsIndexed, FieldNum). En el centro, los registros: MT_Objects describe las filas de MT_Data, que guarda los registros de todas las organizaciones (GUID, OrgID, ObjID, Name y las columnas flexibles Value0 a ValueN); el texto largo se guarda aparte en MT_Clob. El paso 2 añade, a la derecha, las copias hechas para encontrar: cada fila de MT_Data se copia al guardar, como muestra una flecha ámbar, a MT_Indexes (OrgID, ObjID, FieldNum, GUID, StringValue, NumValue, DateValue), y otra caja enumera las demás copias: MT_Unique_Indexes, MT_Relationships, MT_Fallback_Indexes y MT_Name_Denorm. Debajo: todas las tablas llevan OrgID; una columna flexible puede guardar un número de camión para una organización y un sabor de helado para otra, así que los valores indexados se copian en columnas con tipo. METADATOS REGISTROS COPIAS HECHAS PARA ENCONTRAR tiene describe guarda el texto largo en MT_Objects ObjID ID DE REGISTRO OrgID ObjName MT_Fields FieldID ID DE REGISTRO OrgID ObjID FieldName Tipo de datos IsIndexed FieldNum MT_Data GUID ID DE REGISTRO OrgID ObjID Nombre Value0 … ValueN (columnas flexibles) MT_Clob GUID ID DE REGISTRO OrgID Texto largo Todas las tablas llevan OrgID. Una columna flexible puede guardar un número de camión para una organización y un sabor de helado para otra, así que los valores indexados se copian en columnas con tipo. exactamente uno cero o uno uno o muchos cero o muchos © 2026 Twinshark LLC · stevetecharc.com
Clic para ampliar

Unas pocas tablas compartidas lo guardan todo.

Además, todo está particionado por ID de organización, así que una consulta solo mira en la parte de cada tabla que corresponde a tu organización. Salesforce lo llama “poda de particiones” (partition pruning).

La unión que nunca escribiste

Sección titulada «La unión que nunca escribiste »

Esto es algo que sorprende a la gente. Escribes:

SELECT Id, Name, Truck_Number__c FROM WorkOrder

Parece una sola tabla. No lo es. Salesforce guarda por separado los campos estándar y los personalizados: “Para cada tabla de objeto que ves, Salesforce mantiene, a nivel de base de datos, otras tablas separadas para los campos estándar y personalizados. Esta separación, invisible para los clientes, normalmente exige una unión cuando una consulta contiene los dos tipos de campos” (Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27).

Así que Salesforce está haciendo entre bastidores una unión que tú nunca escribiste. Con unos pocos miles de registros, nunca lo notarás. Con decenas de millones, es una de las razones por las que Salesforce ofrece las skinny tables, que veremos en el módulo 4.

La unión que nunca escribiste Arriba, tu consulta: SELECT Id, Name, Truck_Number__c FROM WorkOrder, un objeto y un SELECT. Por debajo lee dos almacenes: los campos estándar (Id, Name, Status, CreatedDate) a la izquierda y los campos personalizados (Id, Truck_Number__c, Crew__c) a la derecha. Entre ellos, en ámbar, los dos se unen por Id. Debajo: invisible para ti, y sin problema con unos pocos miles de registros; con decenas de millones, las skinny tables evitan la unión, en el módulo 4. lee lee unidos por id Tu consulta SELECT Id, Name, Truck_Number__c FROM WorkOrder Campos estándar Id ID DE REGISTRO Nombre Estado CreatedDate Campos personalizados Id ID DE REGISTRO Truck_Number__c Crew__c Invisible para ti, y sin problema con unos pocos miles de registros. Con decenas de millones, las skinny tables evitan la unión (módulo 4). © 2026 Twinshark LLC · stevetecharc.com
Clic para ampliar

La unión que nunca escribiste.

Por qué no encaja un índice normal

Sección titulada «Por qué no encaja un índice normal »

Ahora, el problema del que trata todo este capítulo. Una base de datos tradicional encuentra filas rápido con índices. Pero piensa otra vez en la ranura Value7: para ti es un número de camión, para otro un sabor de helado, para una tercera organización una fecha guardada como texto. No puedes construir un único índice normal de base de datos sobre una columna que guarda tipos de valores distintos para organizaciones distintas.

Salesforce dice exactamente eso: “no es práctico crear índices nativos de base de datos para las columnas flexibles de MT_Data, porque la plataforma usa una sola columna flexible para almacenar los datos de muchos campos con distintos tipos de datos estructurados. En su lugar, la plataforma gestiona un índice de MT_Data copiando de forma síncrona los datos de los campos marcados para indexar a la columna adecuada de una tabla dinámica MT_Indexes.”

Lee esa última frase dos veces, porque el próximo módulo se construye sobre ella:

  • Un índice es una copia. El valor se copia de MT_Data a MT_Indexes, en una columna del tipo adecuado: StringValue, NumValue o DateValue. Ahí es donde puede funcionar un índice real de base de datos.
  • La copia se hace de forma síncrona, al guardar cada registro. Una lectura se vuelve más rápida; cada guardado tiene más trabajo que hacer.

MT_Indexes no es la única tabla adicional. Salesforce mantiene varias, cada una copia de algo, hechas para responder rápido a un tipo de pregunta:

Tabla adicionalPara qué sirve
MT_IndexesEncontrar valores en campos indexados
MT_Unique_IndexesHacer cumplir los campos que deben ser únicos
MT_RelationshipsSeguir rápido las relaciones, en cualquier dirección
MT_Fallback_IndexesBuscar por el Name del registro si el motor de búsqueda no está disponible
MT_Name_DenormMostrar el Name de los registros relacionados
Unas pocas tablas compartidas lo guardan todo Paso 1: las tablas compartidas. A la izquierda, los metadatos: MT_Objects, una fila por objeto (ObjID, OrgID, ObjName), tiene muchas filas en MT_Fields, una fila por campo (FieldID, OrgID, ObjID, FieldName, tipo de datos, IsIndexed, FieldNum). En el centro, los registros: MT_Objects describe las filas de MT_Data, que guarda los registros de todas las organizaciones (GUID, OrgID, ObjID, Name y las columnas flexibles Value0 a ValueN); el texto largo se guarda aparte en MT_Clob. El paso 2 añade, a la derecha, las copias hechas para encontrar: cada fila de MT_Data se copia al guardar, como muestra una flecha ámbar, a MT_Indexes (OrgID, ObjID, FieldNum, GUID, StringValue, NumValue, DateValue), y otra caja enumera las demás copias: MT_Unique_Indexes, MT_Relationships, MT_Fallback_Indexes y MT_Name_Denorm. Debajo: todas las tablas llevan OrgID; una columna flexible puede guardar un número de camión para una organización y un sabor de helado para otra, así que los valores indexados se copian en columnas con tipo. METADATOS REGISTROS COPIAS HECHAS PARA ENCONTRAR tiene describe guarda el texto largo en se copia al guardar en MT_Objects ObjID ID DE REGISTRO OrgID ObjName MT_Fields FieldID ID DE REGISTRO OrgID ObjID FieldName Tipo de datos IsIndexed FieldNum MT_Data GUID ID DE REGISTRO OrgID ObjID Nombre Value0 … ValueN (columnas flexibles) MT_Clob GUID ID DE REGISTRO OrgID Texto largo MT_Indexes OrgID ObjID FieldNum GUID StringValue NumValue DateValue Las demás copias MT_Unique_Indexes MT_Relationships MT_Fallback_Indexes MT_Name_Denorm Todas las tablas llevan OrgID. Una columna flexible puede guardar un número de camión para una organización y un sabor de helado para otra, así que los valores indexados se copian en columnas con tipo. exactamente uno cero o uno uno o muchos cero o muchos © 2026 Twinshark LLC · stevetecharc.com
Clic para ampliar

Paso 2 de 2: Salesforce mantiene copias hechas para encontrar cosas.

El motor se reconstruyó, y no te diste cuenta

Sección titulada «El motor se reconstruyó, y no te diste cuenta »

Esto es algo que ocurrió mientras trabajabas. En los últimos años, Salesforce sustituyó la base de datos que hay debajo de todo esto.

Se llama SalesforceDB. En palabras de Salesforce, es “una base de datos relacional moderna y nativa de la nube, diseñada específicamente para las cargas de trabajo multiinquilino de Salesforce … Amplía PostgreSQL, separa el cómputo y el almacenamiento, y aprovecha Kubernetes y el almacenamiento en la nube”, y “maneja todos los datos transaccionales de CRM, más de 1,1 billones de transacciones al mes” (The Salesforce Platform: Transformed for Tomorrow (se abre en una pestaña nueva)). En la plataforma reconstruida, “cada organización de Salesforce se aloja en una celda de Hyperforce, que incluye el servicio SalesforceDB”: Hyperforce es la infraestructura de Salesforce en la nube pública. El ID del inquilino sigue en cada fila: “Cada registro de tabla incluye un ID de inquilino para distinguir a quién pertenece.”

¿Por qué construir una base de datos? Los propios ingenieros de bases de datos de Salesforce lo explican en un artículo de investigación: “A medida que Salesforce creció a varias regiones y cientos de instancias, gestionar su carga de trabajo multiinquilino en sistemas de bases de datos de proveedores con alta fiabilidad se volvió cada vez más difícil”, así que eligieron “una bifurcación de Postgres” construida para el modelo multiinquilino de Salesforce (Arora y otros, A Multi-tenant Relational OLTP Database at Salesforce (se abre en una pestaña nueva), CIDR 2026).

Y el cambio se hizo con las organizaciones en marcha. En noviembre de 2024, Salesforce escribió que el 85 % de sus clientes se había pasado a la plataforma reconstruida; su documento actual dice que “más del 95 % de nuestros clientes ha hecho la transición a esta nueva plataforma”.

¿Tuviste que reescribir algo? No. Esa es la idea de todo este módulo. Nunca escribiste SQL contra las tablas de Salesforce. Trabajaste con objetos, campos y registros, descritos por metadatos, y Salesforce dice que eso es justo lo que hizo posible el cambio: “Este diseño permite a la plataforma integrar nuevas tecnologías de almacenamiento de datos o modificar las existentes sin necesidad de reescribir las aplicaciones” (misma fuente). El motor se reconstruyó y el coche siguió andando.

Una advertencia honesta. Las tablas compartidas que vimos antes en este módulo son el diseño que documenta Salesforce, en su documento de arquitectura y en su guía de grandes volúmenes de datos de Winter ‘27. Salesforce no ha publicado cómo se organiza físicamente cada una de esas tablas en SalesforceDB, así que tómalas como el diseño, no como una promesa sobre el almacenamiento físico actual. Lo que no ha cambiado es lo que puedes ver: los índices siguen siendo copias, los campos estándar y personalizados se siguen uniendo y las reglas de selectividad del módulo 3 siguen aplicándose.

El motor cambió. El coche no. Dos fotogramas del mismo dibujo. Arriba, sin cambios en ambos: un usuario de Steve Trucking hace una solicitud a la organización de Steve Trucking; debajo, el núcleo, el entorno de ejecución de la aplicación, donde la lógica central más los metadatos de Steve Trucking se unen en el procesamiento. En el primer fotograma, etiquetado antes, la base de datos compartida de abajo es la base de datos anterior, con tablas de metadatos estándar, tablas de metadatos de clientes y tablas de datos compartidas. En el segundo fotograma, la base de datos de abajo es SalesforceDB, la base de datos propia de Salesforce, nativa de la nube y hecha para su carga multiinquilino, dentro de una celda de Hyperforce; guarda los mismos tres tipos de datos, metadatos estándar, metadatos de clientes y datos compartidos, aunque no se ha publicado cómo se organiza cada tabla por dentro. Una llave junto a las tres capas superiores dice el coche: sobre lo que construyes, sin cambios; una llave junto a la base de datos dice el motor: reconstruido por debajo de ti. Un usuario de Steve Trucking hace una solicitud La organización de Steve Trucking su propia vista del esquema, montada en tiempo de ejecución Cuenta Orden de trabajo Socio minorista Referencia de entrega Flow El núcleo, el entorno de ejecución materializa cada organización en tiempo de ejecución Lógica central objetos y capacidades estándar Cuenta Contacto Caso Orden de trabajo Flow Informes Seguridad API Metadatos de Steve Trucking sus objetos, campos y configuración Socio minorista Referencia de entrega formatos flujos uso compartido Procesamiento ejecuta la solicitud sobre sus filas lógica de negocio consultas guardados API + Now: a Hyperforce cell SalesforceDB la base de datos propia de Salesforce, nativa de la nube, hecha para su carga multiinquilino los mismos tres tipos de datos; no se ha publicado cómo se organiza cada tabla por dentro TABLAS DE METADATOS ESTÁNDAR Cuenta Contacto Caso Orden de trabajo Flow, informes, seguridad TABLAS DE METADATOS DE CLIENTES org 1 Socio minorista: un objeto org 2 un campo personalizado org 1 Referencia de entrega: un campo org 3 un objeto personalizado org 1 sus flujos y uso compartido TABLAS DE DATOS COMPARTIDAS org 1 Steve Trucking: una orden de trabajo org 2 otra empresa: un registro org 3 otra empresa: un registro org 1 Steve Trucking: una cuenta org 4 otra empresa: un registro solicitud monta juntos lee solo sus filas lee sus filas escribe sus filas CÓMO LEERLO estándar de Salesforce: igual para todos las filas de Steve Trucking las filas de otras empresas lo que ve su usuario El coche sobre lo que construyes: sin cambios El motor reconstruido por debajo de ti © 2026 Twinshark LLC · stevetecharc.com
Clic para ampliar

El motor cambió. El coche no.

Por qué le importa a un arquitecto

Sección titulada «Por qué le importa a un arquitecto »

No te pedirán que nombres MT_Data en el examen. Pero una vez que has visto el motor, buena parte del comportamiento de Salesforce deja de ser una lista de reglas que memorizar y empieza a tener sentido:

  • Por qué una empresa no puede ver los registros de otra: cada fila lleva su ID de organización, y el núcleo impone la separación en cada consulta.
  • Por qué la seguridad dentro de tu organización sigue siendo tu trabajo: Salesforce protege el edificio; quién recibe la llave de qué habitaciones de tu apartamento es tu diseño.
  • Por qué existen los límites del regulador: todos comparten el edificio.
  • Por qué puedes añadir un campo a la hora de comer: es una fila de metadatos, no un cambio en una tabla.
  • Por qué una consulta sobre campos estándar y personalizados a la vez puede ralentizarse con volumen: la unión que nunca escribiste.
  • Por qué Salesforce tiene sus propias reglas de indexación, y por qué algunos índices personalizados requieren hablar con el soporte de Salesforce: un índice nativo no encaja en las columnas flexibles, así que los valores indexados se copian en tablas hechas para encontrarlos.
  • Por qué los índices tienen un coste: cada copia se actualiza en cada guardado.
  • Por qué Salesforce pudo sustituir su base de datos sin romper tu organización: construyes sobre metadatos, no sobre tablas de base de datos.

Entonces, ¿cómo encuentra Salesforce de verdad tus registros en todo esto? Eso es una biblioteca, y es el próximo módulo.

Conocimiento para el examen. Los nombres de las tablas internas no son materia de examen. Lo que sí lo es: Salesforce es multiinquilino y está basado en metadatos; los campos personalizados no pueden usar índices nativos de base de datos, así que Salesforce mantiene tablas de índices que copian los valores indexados; y una consulta que mezcla campos estándar y personalizados implica una unión, que las skinny tables evitan. SalesforceDB es contexto para un arquitecto, no un dato de examen.

Lo que decide aquí un arquitecto

Sección titulada «Lo que decide aquí un arquitecto »
  • Qué comportamientos explicar a partir del diseño de la plataforma, no de la costumbre: por qué Salesforce no está diseñado como una base de datos dedicada, y qué se deduce de ello.
  • Dónde están los costes ocultos: la unión entre campos estándar y personalizados, y la copia que hay detrás de cada índice.
  • Cuándo un equipo que viene de Oracle o SQL Server necesita oír por qué Salesforce funciona de otra manera, antes de que diseñe como si no fuera así.
  • Qué te toca proteger a ti: Salesforce mantiene separadas las organizaciones; el acceso dentro de tu organización (perfiles, conjuntos de permisos, uso compartido) es tu diseño.
  • Contra qué diseñar: los comportamientos que documenta Salesforce (metadatos, copias de índices, la unión, la selectividad), nunca una disposición física de las tablas, que Salesforce ya ha cambiado una vez por debajo de ti.

Explora

Sección titulada «Explora »

Sígueme

© 2023–2026 Twinshark LLC. All rights reserved. · Uso del contenido

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.

Los avisos legales están en inglés, y prevalece la versión en inglés.