Relacione eventos por ID, nunca por nome de time

Um nome de time é um rótulo, não uma identidade. Clubes mudam de marca, patrocinadores rodam pelos nomes das ligas, e a grafia de um time no feed pode mudar entre dois polls. Se o seu armazenamento relaciona pela string do nome, uma renomeação parece dois times diferentes e seu histórico se parte ao meio. A correção é chavear tudo pelo ID do evento e tratar cada nome como um atributo que pode mudar.

O ID do evento é o único identificador estável

O guia de armazenamento desenha a tabela de eventos em torno do event_id, com liga, casa, fora e início armazenados ao lado, atualizados quando o horário de início ou o status muda, verificado em 2026-10-05. Esse desenho já codifica a regra: o ID identifica o evento; todo o resto o descreve. Um nome que chega diferente amanhã é uma atualização da descrição, não um evento novo.

Siga a mesma regra dentro das suas próprias tabelas. Toda linha de preço, todo registro de alerta e todo snapshot em cache deve carregar o ID do evento como sua chave de junção e nada mais.

Onde a correspondência por nome quebra

A correspondência por nome falha de três formas previsíveis. A renomeação cosmética: uma troca de patrocinador transforma uma string em outra da noite para o dia, e sua deduplicação vê uma partida nova. A deriva de localidade: um feed normaliza um nome acentuado para ASCII simples, e sua cópia armazenada agora discorda do feed. A colisão: dois clubes compartilham um nome curto, e no fim de semana em que ambos jogam, sua junção escolhe um ao acaso.

As três são silenciosas. Nada lança erro; o histórico simplesmente bifurca em silêncio, e você descobre semanas depois, quando uma consulta conta um time como dois.

Registre a renomeação, não lute contra ela

Quando o mesmo ID de evento chega com uma string de nome diferente, atualize os atributos armazenados e escreva uma linha de log: valor antigo, valor novo, o ID. Esse log é sua trilha de auditoria para toda pergunta de identidade depois, e transforma uma bifurcação silenciosa numa mudança revisada.

O mesmo hábito vale a jusante. O código de exibição deve sempre ler nomes do registro do evento, nunca de uma lista fixa, porque o registro é o único lugar que acompanha a grafia atual do feed.

Uma exceção que merece checagem manual

Um ID que você nunca viu não é automaticamente uma renomeação; normalmente é um evento genuinamente novo. Partidas adiadas voltando ao quadro e jogos remarcados podem chegar com IDs novos. Quando um ID novo aparece onde um antigo sumiu com os mesmos times e um horário movido, ligue-os à mão na tabela de eventos e anote, porque essa junção é um julgamento, não uma regra.

IDs para identidade, nomes para exibição, e uma linha de log para cada renomeação. Assim uma mudança de marca vira uma terça-feira, não uma migração de dados.