Verificador de portabilidade de identificadores SQL
Cole um nome de tabela ou coluna proposto — ou uma lista, um por linha — e veja quais entre PostgreSQL, MySQL, SQL Server e SQLite o rejeitariam, renomeariam silenciosamente ou tratariam de maneira inconsistente, e por quê.
O processamento é feito localmente no seu navegador. Seu arquivo nunca é enviado.
Como usar esta ferramenta ferramenta
- Cole um identificador por linha: nome de tabela, coluna ou vários. Nada sai do navegador.
- Selecione ‘Verificar identificadores’.
- Confira cada nome sinalizado: quais mecanismos específicos são afetados, quais não são e por quê.
- Use a reescrita sugerida quando disponível. Colisões com palavras reservadas e escolha do estilo de aspas ficam a seu critério, pois exigem uma decisão que a ferramenta não deve tomar unilateralmente.
Premissas
- A entrada é um identificador por linha: nome simples ou nome já delimitado com o estilo de aspas de um mecanismo (aspas duplas, crases ou colchetes). Não é um parser SQL: uma instrução CREATE TABLE completa ou definição de várias colunas não é analisada, somente o formato do identificador.
- Os quatro mecanismos de destino são PostgreSQL, MySQL, SQL Server (T-SQL) e SQLite — os quatro mais comuns em trabalhos reais de portabilidade entre bancos.
- A tabela de palavras reservadas é um subconjunto selecionado de colisões comuns bem documentadas, não uma lista exaustiva de nenhum mecanismo; consulte Limitações.
Fontes e dados de referência
Metodologia
Cada identificador é verificado contra seis problemas específicos e documentados de portabilidade: colisão com palavra reservada (por mecanismo, pois uma palavra pode ser reservada em um e não em outro), divergência de conversão de maiúsculas/minúsculas (PostgreSQL converte identificadores sem aspas para minúsculas; sensibilidade do MySQL depende do SO/configuração; SQL Server ignora caixa mas a preserva; SQLite diferencia caixa), diferenças na sintaxe de aspas (duplas versus crases versus colchetes), limites de tamanho (63 bytes no PostgreSQL com truncamento silencioso, 64 caracteres no MySQL, 128 no SQL Server, sem limite prático no SQLite), caracteres sem aspas inválidos e convenção de nomes com sublinhado inicial. Reescrita somente nos dois casos mecanicamente inequívocos: converter para minúsculas ou substituir caracteres inválidos por sublinhados; nunca se renomeia palavra reservada nem escolhe estilo de aspas.
Exemplo resolvido
Palavra reservada em alguns mecanismos, mas não em todos
Dados de entrada: limit
Resultado: `limit` é palavra reservada no PostgreSQL, MySQL e SQLite, mas SQL Server não tem cláusula LIMIT (usa TOP/OFFSET-FETCH), portanto não é reservada nele. É sinalizada como erro, identificando exatamente os três mecanismos afetados.
Identificador com maiúsculas e minúsculas
Dados de entrada: CustomerOrder
Resultado: PostgreSQL o converteria silenciosamente para `customerorder` sem aspas, enquanto MySQL, SQL Server e SQLite têm regras de caixa próprias e inconsistentes. É sinalizado como aviso e reescrito para `customerorder`, convenção portátil segura.
Espaços e hífen
Dados de entrada: customer order-id
Resultado: Não é identificador simples válido em nenhum dos quatro mecanismos; cada um exige um tipo diferente de aspas. É sinalizado como erro e reescrito com sublinhados: `customer_order_id`, convenção universalmente segura.
Identificador PostgreSQL acima do limite de bytes
Dados de entrada: an identifier whose encoded length exceeds 63 bytes
Resultado: PostgreSQL limita identificadores a 63 bytes e trunca os maiores; nomes longos distintos podem colidir após o truncamento. O limite em bytes nem sempre equivale ao número de caracteres para texto multibyte. O verificador usa checagens selecionadas, não valida exaustivamente cada identificador ou configuração de banco.
Orientações práticas
- Prefira nomes em minúsculas separados por sublinhados (`snake_case`) para tabelas/colunas consultadas por mais de um mecanismo; isso evita divergências de conversão de caixa.
- Evite palavras reservadas em vez de depender de aspas: elas funcionam, mas cada consulta precisa lembrar de usar permanentemente o estilo de aspas específico do mecanismo.
- Mantenha identificadores bem abaixo de 63 caracteres se PostgreSQL for um destino possível; o truncamento silencioso nesse limite é um modo de falha perigoso.
Erros comuns
- Presumir que um nome é seguro porque não é reservado no banco testado no momento: palavras comuns (order, user, limit, key, index) são reservadas em alguns mecanismos, mas não em outros.
- Tratar aspas como correção universal: o caractere de aspas também varia por mecanismo, então copiar sem alteração um identificador entre aspas de um banco para outro pode falhar.
- Não perceber o truncamento silencioso do PostgreSQL em 63 bytes: ao contrário de uma rejeição, o identificador truncado funciona até que dois nomes longos colidam.
Perguntas frequentes
Por que `limit` é sinalizada em três mecanismos, mas não no SQL Server?
SQL Server não tem cláusula LIMIT; usa TOP ou OFFSET/FETCH. Portanto, LIMIT nunca foi palavra reservada ali. É reservada no PostgreSQL, MySQL e SQLite porque os três usam LIMIT na sintaxe de consulta.
Colocar palavra reservada entre aspas sempre resolve?
Na prática, sim, nos quatro mecanismos aqui, mas o caractere difere: aspas duplas no PostgreSQL/SQLite, crases no MySQL e colchetes no SQL Server. Um nome entre aspas copiado sem alteração de um mecanismo pode não ser analisado por outro. A ferramenta lista a forma equivalente para cada um, sem escolher por você.
Sublinhado inicial é realmente um problema?
Não; é apenas uma nota informativa de baixa gravidade. Não é inválido em nenhum dos quatro mecanismos; vale saber que catálogos internos do PostgreSQL e alguns ORMs usam nomes com sublinhado inicial por convenção.
Última revisão:
A tabela de palavras reservadas é um subconjunto selecionado de colisões comuns verificáveis, não uma lista exaustiva de PostgreSQL, MySQL, SQL Server ou SQLite. Para uma verificação definitiva, consulte a referência oficial do mecanismo antes de finalizar o esquema. A ferramenta também não analisa instruções SQL completas: aceita um identificador por linha, não o corpo de um CREATE TABLE.
As preferências de tema e de ferramentas, além das listas de itens salvos e usados recentemente, são armazenadas somente neste navegador.