IA e bancos de dados MySQL

Um erro notável é que muitos esquemas de banco de dados gerados por IA atualmente favorecem o uso de VARCHAR(36) para a coluna id.

Isso é tipicamente motivado por um desejo de prevenir acesso não autorizado por atores maliciosos. Para conseguir isso, UUIDs (Identificadores Universalmente Únicos) são frequentemente empregados como uma medida de segurança.

Vamos usar o WordPress como exemplo — tipicamente expõe IDs de posts na URL como ?p=45. Comparado com um formato amigável para SEO como /2025/05/sample-post, este ID numérico permite aos usuários potencialmente adivinhar e acessar conteúdo adjacente alterando o número (por exemplo, ?p=44). UUIDs, por outro lado, não são sequenciais e são muito mais difíceis de adivinhar.

UUIDs são strings de 36 caracteres que seguem um formato padrão com cinco seções separadas por hífens: 8-4-4-4-12. Cada seção é composta por valores hexadecimais:

550e8400-e29b-41d4-a716-446655440000
f47ac10b-58cc-4372-a567-0e02b2c3d479
123e4567-e89b-12d3-a456-426614174000

Uma regex simples para validar UUIDs se parece com isso:

^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$

Enquanto UUIDs oferecem segurança e portabilidade, eles vêm com compromissos. Eles são significativamente maiores que inteiros, o que pode tornar o desempenho do banco de dados mais lento — especialmente quando usados como chaves primárias em bancos de dados relacionais. Indexação, uso de memória e velocidade de consulta todas sofrem devido ao tamanho e natureza não sequencial dos UUIDs.

Uma conversa com IA sobre estratégia de ID

Curioso sobre essa escolha de design, fiz a seguinte pergunta ao GitHub Copilot:

Eu:
Por que você escolheu definir a coluna id como VARCHAR(36) PRIMARY KEY na estrutura do banco de dados?

GitHub Copilot:

Escolhi VARCHAR(36) para colunas ID por algumas razões específicas:

1. Armazenamento UUID: O comprimento de 36 caracteres acomoda valores UUID, que seguem um formato padronizado.
2. Sistemas Multi-Inquilino: UUIDs ajudam a isolar inquilinos eliminando vazamentos de ID sequencial, simplificando migrações e melhorando a segurança.
3. Portabilidade de Dados: UUIDs garantem que dados exportados não sofram colisões de ID durante importação para outro sistema.

Compromissos:

• Maior tamanho de armazenamento (36 bytes vs. 4 bytes para INT)
• Desempenho de indexação e consulta mais lento
• Maior uso de memória

Alternativas a considerar:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) para armazenar bytes UUID brutos mais eficientemente
3. Uma estratégia de geração de ID personalizada

Me avise se você prefere uma abordagem diferente.

Eu:
Use BIGINT UNSIGNED para desempenho, mas mantenha um campo guid em cada registro para referências externas.

GitHub Copilot:

Atualizarei o esquema para usar BIGINT UNSIGNED como chave primária enquanto adiciono uma coluna guid para referências externas. Esta abordagem híbrida combina o melhor de ambas as estratégias:

• Desempenho: Indexação e junções eficientes através de chaves primárias numéricas
• Segurança e Portabilidade: GUIDs expostos nas APIs, mantendo IDs internos seguros contra enumeração

Resumo:

• BIGINT UNSIGNED: Rápido, compacto, sequencial
• GUID (VARCHAR): Único, portável, externamente seguro

Bancos de dados NoSQL e ObjectIds do MongoDB

Enquanto bancos de dados relacionais oferecem flexibilidade na escolha entre UUIDs, inteiros ou híbridos, sistemas NoSQL como MongoDB tomam um caminho diferente.

MongoDB usa um tipo embutido chamado ObjectId para seu campo _id. Este é um valor binário de 12 bytes que codifica:

• 4 bytes – Timestamp (segundos desde a época)
• 5 bytes – Valor aleatório (frequentemente baseado em máquina + ID do processo)
• 3 bytes – Contador incremental

Exemplo:

507f1f77bcf86cd799439011

Por que o MongoDB escolhe ObjectId

1. Globalmente único sem coordenação
   Semelhante aos UUIDs, ObjectIds não requerem uma autoridade central para garantir unicidade, tornando-os ideais para ambientes distribuídos.
2. Ordenado por tempo
   O timestamp embutido significa que documentos são ordenados cronologicamente por padrão, o que pode ajudar com desempenho em aplicações de série temporal.
3. Compacto e eficiente
   Armazenados em binário, ObjectIds ocupam apenas 12 bytes — muito menores que um UUID VARCHAR(36). Eles também são mais amigáveis para indexação.

Comparação de estratégias de ID

Preferências de IA em contextos NoSQL

Muitos sistemas gerados por IA padronizam configurações NoSQL semelhantes ao MongoDB quando:

• Alto throughput de escrita ou sharding é esperado
• Esquemas precisam ser flexíveis ou semi-estruturados
• Portabilidade de dados e scaling distribuído são prioridades

Nesses casos, usar ObjectIds ou identificadores únicos similares, ordenáveis por tempo, é frequentemente um padrão sensato.

PrimeCRM