IA y bases de datos MySQL

Un error notable es que muchos esquemas de base de datos generados por IA actualmente favorecen el uso de VARCHAR(36) para la columna id.

Esto está típicamente motivado por el deseo de prevenir acceso no autorizado por actores maliciosos. Para lograr esto, los UUID (Identificadores Universalmente Únicos) se emplean a menudo como medida de seguridad.

Tomemos WordPress como ejemplo — típicamente expone IDs de posts en la URL como ?p=45. Comparado con un formato amigable para SEO como /2025/05/sample-post, este ID numérico permite a los usuarios potencialmente adivinar y acceder a contenido adyacente alterando el número (ej., ?p=44). Los UUID, por otro lado, no son secuenciales y son mucho más difíciles de adivinar.

Los UUID son cadenas de 36 caracteres que siguen un formato estándar con cinco secciones separadas por guiones: 8-4-4-4-12. Cada sección está compuesta de valores hexadecimales:

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

Una expresión regular simple para validar UUID se ve así:

^[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}$

Aunque los UUID ofrecen seguridad y portabilidad, vienen con compromisos. Son significativamente más grandes que los enteros, lo que puede ralentizar el rendimiento de la base de datos — especialmente cuando se usan como claves primarias en bases de datos relacionales. La indexación, uso de memoria y velocidad de consultas sufren debido al tamaño y naturaleza no secuencial de los UUID.

Una conversación de IA sobre estrategia de ID

Curioso sobre esta decisión de diseño, le pregunté a GitHub Copilot lo siguiente:

Yo:
¿Por qué has elegido definir la columna id como VARCHAR(36) PRIMARY KEY en la estructura de base de datos?

GitHub Copilot:

Elegí VARCHAR(36) para las columnas ID por algunas razones específicas:

1. Almacenamiento UUID: La longitud de 36 caracteres encaja con valores UUID, que siguen un formato estandarizado.
2. Sistemas Multi-Inquilino: Los UUID ayudan a aislar inquilinos eliminando filtración de ID secuencial, simplificando migraciones y mejorando seguridad.
3. Portabilidad de Datos: Los UUID aseguran que los datos exportados no sufran de colisiones de ID durante la importación a otro sistema.

Compromisos:

• Mayor tamaño de almacenamiento (36 bytes vs. 4 bytes para INT)
• Rendimiento de indexación y consulta más lento
• Mayor uso de memoria

Alternativas a considerar:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) para almacenar bytes UUID raw más eficientemente
3. Una estrategia de generación de ID personalizada

Házmelo saber si prefieres un enfoque diferente.

Yo:
Usa BIGINT UNSIGNED para rendimiento, pero mantén un campo guid en cada registro para referencias externas.

GitHub Copilot:

Actualizaré el esquema para usar BIGINT UNSIGNED como clave primaria mientras agrego una columna guid para referencias externas. Este enfoque híbrido combina lo mejor de ambas estrategias:

• Rendimiento: Indexación y joins eficientes vía claves primarias numéricas
• Seguridad y Portabilidad: GUIDs expuestos en APIs, haciendo IDs internos seguros contra enumeración

Resumen:

• BIGINT UNSIGNED: Rápido, compacto, secuencial
• GUID (VARCHAR): Único, portable, externamente seguro

Bases de datos NoSQL y ObjectIds de MongoDB

Mientras las bases de datos relacionales ofrecen flexibilidad para elegir entre UUID, enteros o híbridos, los sistemas NoSQL como MongoDB toman un camino diferente.

MongoDB usa un tipo incorporado llamado ObjectId para su campo _id. Este es un valor binario de 12 bytes que codifica:

• 4 bytes – Timestamp (segundos desde época)
• 5 bytes – Valor aleatorio (a menudo basado en máquina + ID de proceso)
• 3 bytes – Contador incremental

Ejemplo:

507f1f77bcf86cd799439011

Por qué MongoDB elige ObjectId

1. Globalmente único sin coordinación
   Similar a los UUID, los ObjectIds no requieren una autoridad central para asegurar unicidad, haciéndolos ideales para entornos distribuidos.
2. Ordenado por tiempo
   El timestamp embebido significa que los documentos están ordenados cronológicamente por defecto, lo que puede ayudar con rendimiento en aplicaciones de series temporales.
3. Compacto y eficiente
   Almacenados en binario, los ObjectIds toman solo 12 bytes — mucho más pequeño que un UUID VARCHAR(36). También son más amigables para indexación.

Comparando estrategias de ID

Preferencias de IA en contextos NoSQL

Muchos sistemas generados por IA usan por defecto configuraciones NoSQL similares a MongoDB cuando:

• Se espera alto throughput de escritura o sharding
• Los esquemas necesitan ser flexibles o semiestructurados
• La portabilidad de datos y escalado distribuido son prioridades

En estos casos, usar ObjectIds o identificadores únicos similares, ordenables por tiempo, es a menudo un defecto sensible.

PrimeCRM