Posted on: July 31, 2025 02:54 PM
Posted by: Renato
Views: 159
Sobre Universally Unique Identifier uuid
Usar UUID (Universally Unique Identifier) como chave primária em bancos de dados pode ser uma escolha estratégica, dependendo do cenário. Aqui vai um balanço dos prós e contras pra te ajudar a avaliar:
Hoje
Quais os pos e contras usar em banco de dados uuid?
Ótima pergunta, Renato! Usar UUID (Universally Unique Identifier) como chave primária em bancos de dados pode ser uma escolha estratégica, dependendo do cenário. Aqui vai um balanço dos prós e contras pra te ajudar a avaliar:
✅ Vantagens do uso de UUID
-
Unicidade global: Ideal para sistemas distribuídos ou microsserviços, pois você pode gerar IDs únicos sem precisar consultar o banco.
-
Evita colisões: Especialmente útil em ambientes onde várias instâncias geram dados simultaneamente.
-
Independência da ordem de inserção: Diferente de IDs auto-incrementais, o UUID não depende do momento da inserção no banco.
-
Privacidade e segurança: Dificulta a engenharia reversa ou exposição de quantos registros existem (como
id=1000).
❌ Desvantagens do uso de UUID
-
Performance: Pode degradar a performance em índices, especialmente em bancos que usam B-tree, por ser menos sequencial.
-
Espaço de armazenamento: Um UUID ocupa 16 bytes (ou 36 caracteres se armazenado como string), bem mais que um
INT(normalmente 4 bytes). -
Leitura e depuração: Difícil de memorizar, digitar e entender em logs ou testes manuais.
-
Desordem nos dados: Se o UUID for aleatório, pode causar fragmentação nos índices e queda no desempenho de consultas.
👉 Alternativas e mitigação
-
Usar UUIDs ordenados (como UUID v1 ou v6) ajuda a preservar parte da performance de escrita sequencial.
-
Armazenar UUID como binário (BINARY(16)) ao invés de string pode economizar espaço e melhorar performance.
Se você estiver lidando com sistemas distribuídos, replicação ou precisa de IDs gerados fora do banco, o UUID pode ser uma ótima pedida. Mas pra sistemas locais com alto volume de dados e consultas intensas, talvez o clássico INT seja mais eficiente.
Num sistema de chamados, usar UUID como identificador pode ser uma excelente escolha — especialmente se você espera crescer, integrar com outros serviços ou distribuir o sistema em múltiplos servidores. Vamos olhar com mais carinho pro seu cenário, Renato:
🧾 Por que UUID funciona bem em sistemas de chamados
-
Distribuição garantida: Sistemas de atendimento muitas vezes operam com múltiplas instâncias (ex: apps móveis, APIs), e o UUID permite que cada chamado seja criado com um ID único localmente — sem esperar pelo banco.
-
Integrações seguras: Se o sistema precisar expor IDs publicamente (em URLs, e-mails ou integrações com terceiros), o UUID é mais seguro que um
INTsequencial, já que não revela a quantidade total de registros. -
Sincronização simplificada: Se você tiver múltiplos bancos ou precisar replicar dados, o UUID ajuda a evitar colisões na hora de mesclar os chamados.
⚠️ Mas vale cuidar de alguns pontos...
-
Performance de busca: Use UUIDs ordenáveis (ex: UUID v1 ou UUID v7) pra reduzir fragmentação e melhorar eficiência dos índices.
-
Formato de armazenamento: Prefira armazenar como
BINARY(16)ao invés deCHAR(36)— isso reduz uso de espaço e melhora performance. -
Legibilidade nos logs: Uma alternativa é manter um campo extra com um identificador legível (ex:
ticket-2024-00023) para facilitar suporte e rastreamento.
Se você estiver construindo um sistema com potencial para escalar ou integrar com outros serviços, UUID pode te salvar muitas dores de cabeça. E esse exemplo que você mandou — "uuid": "698729af-7071-4b40-983b-a26adb86c925" — está com cara de UUID v4 (aleatório), o que é bom pra segurança, mas pode gerar fragmentação se usado como chave primária.
No Laravel, trabalhar com UUID como chave primária é super viável, e vou te mostrar um exemplo bem prático de como configurar isso direitinho. Bora lá!
⚙️ Passo a passo para usar UUID como ID no Laravel
1. Criar a migration da tabela
php artisan make:migration create_chamados_table
No arquivo da migration:
Schema::create('chamados', function (Blueprint $table) {
$table->uuid('id')->primary(); // Chave primária como UUID
$table->string('titulo');
$table->text('descricao');
$table->timestamps();
});
💡 Dica: se quiser armazenar o UUID em formato binário, pode usar
$table->binary('id')e ajustar o model.
2. Configurar o Model
No Chamado.php (model):
use Illuminate\Support\Str;
class Chamado extends Model
{
public $incrementing = false; // Desativa incremento automático
protected $keyType = 'string'; // UUID é string
protected static function boot()
{
parent::boot();
static::creating(function ($model) {
if (empty($model->{$model->getKeyName()})) {
$model->{$model->getKeyName()} = (string) Str::uuid();
}
});
}
}
.
3. Criar registros
Chamado::create([
'titulo' => 'Erro no sistema',
'descricao' => 'Usuário não consegue logar.',
]);
Isso já salva seu chamado com um UUID no campo id, tipo: 698729af-7071-4b40-983b-a26adb86c925
🧪 Testando na prática
Você pode ver os dados com:
Chamado::all()->pluck('id');
Donate to Site
Renato
Developer