Cada estructura es un compromiso

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

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

Capítulo 3 de Data Architect, Parte 1: Convertirse en Data Architect. Anterior: Modelar los datos con sentido.

Esta es una pregunta que hago en cada clase. Si alguien dice “trabajo con Salesforce”, ¿cuál es el nombre de API del objeto producto?

Es Product2. Es mi primera prueba de fuego. En algún momento, Salesforce construyó el objeto producto, se dio cuenta de que no funcionaba y tuvo que dejarlo atrás. No podían simplemente quitarlo, así que agregaron Product2. Hasta Salesforce vive con sus estructuras antiguas.

Salesforce también se dejó espacio para crecer. Sus objetos estándar no llevan prefijo ni sufijo, y nosotros, quienes personalizamos las organizaciones, nunca podemos ocupar ese espacio. Así que Salesforce puede seguir agregando objetos sin chocar nunca con nada que construyamos.

La lección es esta: crear un objeto lleva diez minutos. Vivir con él lleva años. Cada objeto y cada campo que agregas es un compromiso. Ocupa almacenamiento. Acumula límites. Recibe un modelo de uso compartido, lo hayas diseñado o no. Necesita una licencia para cada persona que lo toca. Y ahora también lo lee la IA, así que cómo lo nombras y cómo lo describes decide lo que un agente entiende sobre tus datos. Agregar es fácil. Quitar es difícil.

Este capítulo convierte los bloques de construcción de Salesforce en decisiones.

Imagen generada con IA.

Las estructuras de un vistazo

Salesforce te da seis lugares para guardar datos. Los pongo en una sola diapositiva, porque el primer trabajo es saber que todos existen:

Estructura	Para qué sirve	La trampa
Objetos estándar	El modelo propio de Salesforce: cuenta, contacto, oportunidad, caso, activo y el resto	Úsalos para lo que están pensados, o te pelearán
Objetos personalizados	Los datos propios de tu negocio	Fáciles de crear, difíciles de retirar
Objetos externos	Datos que viven en otro sistema y se muestran en Salesforce	Cada acceso es una llamada externa (callout)
Objetos grandes	Volúmenes enormes que debes conservar pero que rara vez abres	Sin interfaz ni informes estándar; consultas a través del índice
Archivos	Documentos, fotos y otro contenido	El almacenamiento de archivos sube rápido
Datos adjuntos	La forma antigua de guardar archivos	Heredado: usa Archivos

Elegir una es solo una parte. Antes de la estructura viene la pregunta de dónde deberían vivir los datos, para empezar: en el núcleo, referenciados donde ya están, o archivados.

El recorrido de este capítulo

Este capítulo es grande, así que viene en diez partes. Cada una se sostiene por sí sola. En el capítulo 2 decidimos cómo debería ser el modelo; aquí decidimos cómo debería vivir en Salesforce.

1. La plataforma de datos de Salesforce: más que una base de datos. Qué hace distinto a Salesforce, y por qué la plataforma tiene una forma.
2. Mira a la nave nodriza: los modelos de datos estándar. Los modelos de Ventas y Servicio que Salesforce ya construyó, los archivos, el almacenamiento y las cuentas personales.
3. Construye el tuyo: objetos personalizados. Lo que decide la pantalla New Custom Object, los campos que tú no creaste y cómo leer cualquier nombre de API: estándar, personalizado o de paquete gestionado.
4. ¿Dónde viven estos datos? En el núcleo, referenciados o archivados: se decide antes de crear cualquier objeto.
5. Elige el objeto correcto. La prueba del ajuste limpio, el equipaje que traen los objetos estándar, las cuentas personales y las licencias que deciden lo que la gente puede usar.
6. Los campos también son arquitectura. Tipo de campo por tipo de campo, los comportamientos que sorprenden a la gente, y por qué cada campo lleva una descripción.
7. Las relaciones tienen consecuencias. Búsqueda o principal-detalle, tres niveles de profundidad y dos padres de ancho, el objeto de unión lógico y el objeto de unión de Salesforce, y los límites que muerden.
8. Propiedad y ciclo de vida. Quién es dueño de un registro, la tabla de uso compartido donde la propiedad se convierte en acceso, y qué le pasa a un registro a lo largo de su vida.
9. Mantener los datos consistentes. La escalera de la consistencia: cada capa tiene un costo, y nunca “arreglas” el historial para cumplir una regla nueva.
10. Diseña el modelo físico de Salesforce. Una porción de Steve Trucking, del modelo lógico a Salesforce, construida paso a paso, con el razonamiento.

Cuando termines, ponte a prueba con la guía de estudio del capítulo: una lista de verificación para el examen, los hábitos que van más allá, las palabras que conviene conocer y algunas preguntas.

Lo que decide aquí un arquitecto

• Lo que Salesforce ya modela, antes de inventar nada: mira a la nave nodriza.
• Dónde vive cada tipo de dato, en el núcleo, referenciado o archivado, antes de elegir una estructura.
• Qué estructura lo guarda, sabiendo a qué renuncia cada una.
• Cómo se relacionan los objetos, quién es dueño de los registros, y lo que eso significa para el acceso y la escala.
• De qué licencias depende el modelo, comprobado antes de diseñar los objetos, no después.
• Cómo se mantienen consistentes los datos, y lo que cuesta cada capa de consistencia.

Más allá del examen: la construcción asistida por IA puede crear objetos y campos en minutos. Cuando agregar es casi gratis, “cada estructura es un compromiso” importa más, no menos. Cada módulo termina con lo que la IA cambia en esa decisión.

Explora

• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Ayuda de Salesforce (en inglés)
• Standard User Licenses (opens in a new tab), Ayuda de Salesforce (en inglés)

Siguiente: Entender los datos de la empresa