Claves primarias en Snowflake: cuándo permiten duplicados

El modelo tiene su clave primaria, el diagrama está ordenado y la carga termina sin errores. Días después, un informe suma más ventas de las que existen. Alguien encuentra dos filas para el mismo cliente y aparece una pregunta razonable: «¿Cómo han entrado si esa columna era la clave?».

En Snowflake, la respuesta depende del tipo de tabla. En una tabla estándar, declarar PRIMARY KEY no hace que el motor impida los duplicados. Confundir esa declaración con una barrera efectiva deja un hueco entre lo que el equipo cree que está protegido y lo que realmente puede entrar.

Ese hueco merece una conversación de arquitectura. La integridad que necesitamos debe tener un mecanismo, un momento de comprobación y una consecuencia cuando falla. El nombre de una restricción, por sí solo, no resuelve ninguno de los tres.

Qué garantiza realmente una clave en Snowflake

La documentación de restricciones de Snowflake distingue tablas estándar e híbridas. En las primeras, PRIMARY KEY, UNIQUE y FOREIGN KEY son declarativas y no se hacen cumplir. NOT NULL y CHECK sí se aplican. En las híbridas, la clave primaria es obligatoria y se hace cumplir, al igual que UNIQUE y FOREIGN KEY cuando se definen. CHECK también se aplica en las tablas híbridas, pero debe definirse al crear la tabla; no puede añadirse después. Además, una tabla híbrida con CHECK no admite cargas mediante COPY INTO, según las limitaciones documentadas de las tablas híbridas.

Por tanto, «Snowflake no aplica restricciones» también es una explicación incorrecta. Oculta diferencias que pueden cambiar una decisión de diseño. Lo relevante es qué restricción estamos usando, sobre qué tipo de tabla y con qué comportamiento documentado.

Declarar relaciones sigue teniendo utilidad: comunica el modelo y puede ayudar a las herramientas que consumen sus metadatos. Pero comunicar una intención y proteger una escritura son funciones distintas. Cuando alguien migra desde un sistema donde la clave rechazaba un segundo registro, necesita revisar esa expectativa expresamente.

Un duplicado pequeño puede multiplicar una cifra grande

Imaginemos un caso hipotético con 100 pedidos de 20 euros cada uno. Las ventas suman 2.000 euros. La dimensión de clientes contiene por error dos filas para el cliente que hizo diez de esos pedidos. Si el informe relaciona pedidos y clientes por ese identificador, esos diez pedidos encuentran dos coincidencias cada uno.

El resultado tiene 110 filas y suma 2.200 euros: un exceso del 10 %, aunque solo se haya duplicado una identidad en la dimensión. Son cifras ilustrativas calculadas para este ejemplo, no una medición de Snowflake ni un incidente de un cliente.

Esto explica por qué el porcentaje global de filas duplicadas puede ser un indicador engañoso. La consecuencia depende también de dónde se concentra el error y de cómo se reutiliza la relación. Una duplicidad en una entidad con mucha actividad puede afectar a numerosas decisiones posteriores.

También obliga a precisar qué significa «duplicado». Dos versiones históricas de un cliente pueden ser legítimas. En ese modelo, relacionar solo por el identificador comercial puede ser insuficiente: falta la versión o el periodo aplicable. Borrar una de las filas para que desaparezca la alerta podría destruir información correcta sin arreglar la relación equivocada.

RELY añade una promesa que hay que sostener

El asunto se vuelve más delicado cuando los metadatos influyen en la optimización. Snowflake documenta que RELY permite eliminar determinados joins redundantes al asumir que se cumplen las restricciones declaradas. También advierte de que, si esa integridad no se mantiene, los resultados pueden diferir respecto a NORELY.

Podemos interpretar RELY como una promesa que hacemos al optimizador. La propiedad no limpia los datos ni sustituye su control. La referencia de propiedades de las restricciones señala además que las violaciones pueden llevar a insertar datos incorrectos mediante operaciones DML y CTAS cuando interviene RELY.

La decisión, entonces, no debería reducirse a si una consulta tarda menos. Hace falta saber qué sostiene la promesa durante una carga normal, una corrección manual o un reprocesado histórico. Un control que se ejecutó una vez al implantar el modelo no demuestra que siga cumpliéndose hoy.

La ficha de garantía de integridad

Para hacer visible ese compromiso propongo una ficha de garantía de integridad. Es una síntesis de análisis para este artículo, no un estándar del proveedor ni un modelo validado externamente. Cada regla importante debería poder describirse con estas cinco piezas:

Regla y alcance

Qué debe ser único o estar relacionado, para qué conjunto de datos y en qué periodo. «Un cliente» resulta ambiguo si convivimos con varias versiones históricas.

Mecanismo

Qué impide o detecta el incumplimiento: una restricción aplicada por el motor, una validación de publicación o una comprobación posterior. Son protecciones con efectos diferentes.

Momento

Si la comprobación ocurre antes de que el dato esté disponible para consumo o después. Una alerta tardía deja una ventana de exposición.

Consecuencia

Qué sucede con un dato inválido: bloqueo de la nueva versión, cuarentena, conservación del último conjunto válido o consumo con una limitación explícita.

Responsable y evidencia

Quién puede corregir el origen y qué registro permite demostrar que la regla se cumplió en la versión utilizada.

En el ejemplo de los pedidos, la ficha podría exigir una sola fila vigente por identidad de cliente antes de publicar la dimensión para informes. Si la comprobación falla, la propuesta sería conservar la última versión válida y avisar del retraso. Esa opción protege las sumas a cambio de perder frescura. No siempre será el intercambio adecuado, pero al menos podemos discutirlo con claridad.

La ficha tiene un límite deliberado: no decide por nosotros si el modelo representa bien el negocio. Una clave perfectamente única puede identificar la entidad equivocada. También necesita evidencia del proceso real, porque rellenar los campos no convierte una intención en garantía.

Detectar después y bloquear antes tienen costes distintos

Una comprobación nocturna puede ser suficiente para un análisis exploratorio. Para un dato que determina una acción automática, las horas transcurridas hasta la detección pueden importar mucho más. El criterio no es exigir bloqueo a todo, sino entender qué decisiones quedan expuestas durante ese intervalo.

Es la misma pregunta que aparece al valorar la ventana útil de los datos en tiempo real: importa cuándo alguien necesita actuar y con qué información. Aquí añadimos otra condición: qué evidencia permite confiar en la relación que sostiene esa acción.

Cambiar a una tabla híbrida tampoco debería ser una reacción automática. La referencia de tablas híbridas describe restricciones e índices con comportamiento propio, incluidas relaciones externas limitadas a tablas híbridas de la misma base de datos. Elegir ese tipo de almacenamiento exige revisar el conjunto de la carga, no resolver una sorpresa aislada.

La próxima vez que un diagrama muestre una clave, la conversación útil puede empezar por algo muy concreto: ¿qué ocurriría si esta tarde entraran dos filas que incumplen esa promesa? Si la respuesta es «nos enteraríamos mañana», ya sabemos qué garantía tenemos y cuál todavía falta.