Gerador de nomes de tabelas de banco de dados

Ler a tabela antes das colunas

O nome de uma tabela se repete em todos os lugares por onde os dados passam: código, SQL, migrações, painéis, relatórios de incidentes e conversas. Essa repetição transforma a nomeação em decisão arquitetural. CustomerContactDetails deve identificar as linhas diretamente. UserRoleAssignments torna o relacionamento visível. SchemaMigrationLocks indica, por outro lado, que a tabela coordena trabalho e não representa um objeto de negócio.

Relacionar o nome ao ciclo de vida

O ciclo de vida costuma fornecer o qualificativo decisivo. PaymentEvents implica histórico apenas acrescentado. DailySalesRollups indica agregados derivados. StagedCustomers sugere registros importados aguardando validação. ArchivedCustomerRecords avisa que as linhas não estão ativas. CacheInvalidationEvents lida com dados derivados, e DataErasureRequests carrega expectativas de privacidade e workflow. Use essas palavras somente quando constraints, retenção e padrões de escrita as tornarem verdadeiras.

Combinar linguagem de negócio e precisão técnica

Bons nomes conectam o vocabulário do produto à estrutura do banco. Use termos compreendidos por suporte, finanças, operações e análise, acrescentando qualificadores técnicos apenas quando resolvem ambiguidade real. InvoicePaymentAllocations é útil se a alocação for uma ação própria. CountryCodes basta para um catálogo pequeno. TenantNotificationRules é adequado quando cada linha pertence a um tenant. Evite números de versão ou nomes temporários de serviços que desaparecerão antes dos dados.

Revisão rápida do nome

• Nomear primeiro a entidade ou o evento central.
• Reservar Logs, Events, Audits e History para ciclos de vida realmente distintos.
• Aplicar a mesma lógica a todas as tabelas de junção.
• Usar Staged, Cached, Archived ou Rollup apenas quando o qualificativo for verdadeiro.
• Preferir substantivos de domínio estáveis a rótulos temporários de implementação.

Perguntas antes da próxima migração

Teste cada proposta em um JOIN, no título de uma migração e em um alerta. Verifique quem possui os dados, se eles representam estado ou histórico e se uma tabela próxima já usa o mesmo substantivo. Escolha então o nome mais curto que preserve essas diferenças.

• O que uma pessoa de plantão deduziria apenas pelo nome?
• Que palavra distingue esta tabela da vizinha mais próxima?
• O nome continuará funcionando quando a funcionalidade atual mudar?
• Que constraint ou ciclo de vida deveria ser sugerido discretamente?