SOQL

SOQL (Salesforce Object Query Language) es el lenguaje de consultas propio de Salesforce que sirve para leer datos almacenados en los objetos de la plataforma. Su sintaxis recuerda a SQL (usa SELECT ... FROM ... WHERE), pero opera sobre los objetos de Salesforce (estándar y personalizados) en lugar de tablas de una base de datos tradicional, y devuelve registros que el código luego procesa.

A diferencia de SQL, SOQL solo recupera datos: no tiene INSERT, UPDATE ni DELETE (esas operaciones se hacen con DML en Apex), no permite SELECT \* (hay que nombrar cada campo) y no hace joins arbitrarios, sino que navega las relaciones ya definidas entre objetos. Es una de las herramientas centrales con las que trabaja quien programa sobre la plataforma, parte del oficio que cubre el equipo de desarrolladores de Salesforce.

Para qué se usa SOQL

Cada vez que una pantalla, un automatismo o un fragmento de código en Salesforce necesita traer registros (las cuentas de una región, las oportunidades abiertas de un vendedor, los casos sin resolver), por debajo casi siempre hay una consulta SOQL. Se escribe dentro de Apex, en componentes Lightning Web Components, en herramientas de integración o directamente en el Developer Console para inspeccionar datos. Es el puente entre la lógica de negocio y la información guardada en la org.

Una consulta típica selecciona el nombre, el monto y la etapa de las oportunidades cuyo monto supera cierto umbral, ordenadas por fecha de cierre. La gran diferencia con una base relacional clásica es cómo trata las relaciones entre objetos: en lugar de armar joins, SOQL aprovecha las relaciones que ya existen en el modelo de datos. Para subir de un registro hijo a su padre se usa notación de punto (el contacto accede a campos de su cuenta), y para bajar a los hijos se usa una subconsulta de relación (desde una cuenta se piden sus contactos). Esto hace que las consultas sean más legibles, pero también que estén atadas al esquema definido en la plataforma.

Por qué importa para un negocio

Aunque suene a detalle técnico, SOQL tiene consecuencias directas en lo que percibe el usuario. Una consulta bien escrita es la diferencia entre un reporte que carga al instante y uno que tarda o falla. En Argentina y LATAM, donde es común tener orgs con cientos de miles de registros (clientes, facturas, casos de soporte), el costo de las consultas mal diseñadas se nota: pantallas lentas, automatizaciones que se caen y procesos nocturnos que no terminan a tiempo.

Hay un motivo concreto detrás. Salesforce es una arquitectura multitenant (muchas empresas comparten la misma infraestructura), así que impone governor limits: topes a cuántas consultas SOQL y cuántos registros puede manejar una transacción. Si el código los supera, la operación se interrumpe. Por eso escribir SOQL eficiente no es un lujo: es lo que mantiene la plataforma estable para todos.

SOQL vs SQL: en qué se diferencian

Vienen de mundos parecidos, pero no son intercambiables. Esta tabla resume las diferencias clave:

Quien viene de SQL aprende SOQL rápido en lo básico, pero tropieza con lo que falta: no hay forma de traer todas las columnas con un comodín, no hay joins libres y siempre hay que pensar en los límites.

Errores comunes que conviene evitar

• Consultas dentro de un bucle (loop): repetir una consulta por cada registro de una lista agota rápido los límites. La regla es bulkificar: una sola consulta que traiga todo lo necesario de una vez.
• Traer más campos o registros de los necesarios: pedir campos que no se usan o no filtrar infla el consumo y la latencia. Conviene acotar con condiciones y, cuando aplica, con un límite de filas.
• No filtrar por campos indexados: consultar sobre campos no indexados en tablas grandes obliga a recorrer todo, lo que dispara errores de tiempo en orgs con mucho volumen.
• Confundir SOQL con SQL: intentar un comodín de columnas o un join que no existe en el modelo termina en error de sintaxis.

Ejemplo concreto

Una distribuidora de Consumo Masivo en Buenos Aires quiere mostrarle a cada vendedor sus cuentas con saldo pendiente. En vez de consultar cuenta por cuenta (lo que con 5.000 clientes reventaría los límites), el desarrollo arma una sola consulta que filtra por dueño y por estado de cobranza, ordena por monto y la presenta en un componente. Resultado: la pantalla carga en segundos y el proceso escala sin tocar los topes de la plataforma. Esa decisión, invisible para el usuario final, es la clase de buena práctica de SOQL que separa una implementación robusta de una que se cae cuando crecen los datos.