NOTAS DE CAPACIDAD
Relaciona eventos por ID, nunca por nombre de equipo
Los nombres de equipos son cadenas de pantalla y cambian. Clavea tu almacén por el ID del evento, trata los nombres como atributos y registra cada renombrado.
Un nombre de equipo es una etiqueta, no una identidad. Los clubes cambian de marca, los patrocinadores rotan por los nombres de las ligas, y la grafía de un equipo en el feed puede cambiar entre dos sondeos. Si tu almacén relaciona por la cadena del nombre, un renombrado parece dos equipos distintos y tu historial se parte en dos. La solución es clavear todo por el ID del evento y tratar cada nombre como un atributo que puede cambiar.
El ID del evento es el único identificador estable
La guía de almacenamiento diseña la tabla de eventos alrededor del event_id, con liga, local, visitante e inicio almacenados al lado, actualizados cuando la hora de inicio o el estado cambian, verificado el 2026-10-05. Ese diseño ya codifica la regla: el ID identifica el evento; todo lo demás lo describe. Un nombre que llega distinto mañana es una actualización de la descripción, no un evento nuevo.
Sigue la misma regla dentro de tus propias tablas. Cada fila de precio, cada registro de alerta y cada snapshot en caché debe llevar el ID del evento como su clave de unión y nada más.
Dónde se rompe la correspondencia por nombre
La correspondencia por nombre falla de tres formas previsibles. El renombrado cosmético: un cambio de patrocinador convierte una cadena en otra de la noche a la mañana, y tu deduplicación ve un partido nuevo. La deriva de localidad: un feed normaliza un nombre acentuado a ASCII plano, y tu copia almacenada ahora discrepa con el feed. La colisión: dos clubes comparten un nombre corto, y el fin de semana en que ambos juegan, tu unión elige uno al azar.
Las tres son silenciosas. Nada lanza un error; el historial simplemente se bifurca en silencio, y te enteras semanas después, cuando una consulta cuenta un equipo como dos.
Registra el renombrado, no luches contra él
Cuando el mismo ID de evento llega con una cadena de nombre distinta, actualiza los atributos almacenados y escribe una línea de log: valor viejo, valor nuevo, el ID. Ese log es tu pista de auditoría para toda pregunta de identidad después, y convierte una bifurcación silenciosa en un cambio revisado.
El mismo hábito aplica aguas abajo. El código de pantalla debe leer siempre los nombres del registro del evento, nunca de una lista fija, porque el registro es el único lugar que sigue la grafía actual del feed.
Una excepción que merece revisión manual
Un ID que nunca has visto no es automáticamente un renombrado; normalmente es un evento genuinamente nuevo. Los partidos aplazados que vuelven al tablero y los encuentros reprogramados pueden llegar con IDs nuevos. Cuando un ID nuevo aparece donde uno viejo desapareció con los mismos equipos y una hora movida, enlázalos a mano en la tabla de eventos y anótalo, porque esa unión es un juicio, no una regla.
IDs para la identidad, nombres para la pantalla, y una línea de log por cada renombrado. Así un cambio de marca se vuelve un martes, no una migración de datos.