Digestivo Ou Digestorio

O problema da grafia: digestivo ou digestório?

Essa é uma dúvida que aparece com frequência em planilhas, formulários e até em código, porque o português brasileiro tem duas grafias aceitas. Digestivo é a forma mais comum e a que você vai encontrar na maioria dos dicionários e textos técnicos. Digestório também é válida — é uma variante com "-ório", que segue um padrão que existe em outras palavras como "arquivório" e "almoxarifado". Ninguém vai te obrigar a escolher uma, mas a inconsistência gera confusão, especialmente quando você está integrando dados de diferentes sistemas. Eu comecei a notar isso em 2018, quando migrei os cadastros de um cliente do antigo sistema para uma base nova. Vinha uma coluna chamada "classe_digestivo" e outra "tipo_digestorio", eram a mesma coisa, só que com grafias diferentes. O resultado? Registros duplicados porque a validação não reconhecia que era o mesmo campo. A solução que eu encontrei foi simples: padronizei tudo para digestivo no banco e fiz um mapa de equivalência no ETL que transformava "digestorio" em "digestivo" antes da inserção. Isso economizou horas de limpeza manual.

Como resolver digestivo ou digestorio na prática

Se você está lidando com isso em um projeto de dados, aqui vai o caminho que funciona sem muito custo. Primeiro, defina qual grafia será a padrão do seu time. No Brasil, digestivo é a forma predominante e a que vai causar menos atrito com bibliotecas, APIs e documentação. Depois, trate a questão em três camadas: No front-end: use autocompletar ou um campo de seleção (select) em vez de deixar o usuário digitar livremente. Se tiver que aceitar texto livre, valide contra uma lista fechada de opções aceitáveis — "digestivo", "digestorio", e talvez uma versão em espanhol se o sistema atender outros países. No back-end: normalize a entrada antes de salvar. Um trivial `lower().strip()` seguido de um replace de "digestorio" por "digestivo" resolve 99% dos casos. Cuidado apenas com falsos positivos — se houver campos que contenham essas strings como parte de palavras maiores, o replace cego pode estragar algo. Nesse caso, use regex com delimitadores de palavra: `\bdigestorio\b`.

No banco de dados: se a tabela já existe e tem valores inconsistentes, rode uma migração única: UPDATE tabela SET campo = 'digestivo' WHERE campo = 'digestorio'. Sempre faça backup antes e teste em staging primeiro. Eu perdi meia hora numa vez porque esqueci de testar em staging e o update errada atingiu 40 mil linhas em vez das 3 mil que precisavam de correção. Não recomendo repetir esse erro. Para quem quer um script pronto, um replace em Python ficaria assim: import re
valor = valor.strip().lower()
valor = re.sub(r'\bdigestorio\b', 'digestivo', valor)


Isso leva cerca de 2 segundos para processar um lote de 10 mil registros em hardware comum.

Por que a variação existe

A grafia "digestório" não é inventada. O sufixo "-ório" é produtivo em português para formar substantivos relacionados a lugares ou conjuntos, e historicamente alguns autores e dicionários registraram essa variante. O Caldas Aulete e o Michaelis aceitam ambas as formas. A BBC, contudo, recomenda o uso de "digestivo" em textos técnicos por ser a forma mais difundida e menos ambígua. Em outros idiomas a coisa muda. No espanhol, "digestivo" é a forma padrão e "digestorio" quase não aparece. Se seu sistema atende públicos de países lusófonos e hispanófonos, a consistência interna fica ainda mais crítica — um mesmo campo pode receber entradas de diferentes origens geográficas.

Alternativas e armadilhas

Se o problema é recorrente no seu projeto, uma opção mais robusta do que normalizar texto puro é usar códigos ao invés de strings. Em vez de salvar "digestivo" ou "digestorio", salve um ID numérico ou um código padronizado (por exemplo, "DIG-01"). A apresentação para o usuário final pode mostrar o termo em português, mas o armazenamento interno fica livre de variantes ortográficas. Isso elimina a necessidade de normalização e reduz a chance de inconsistência para praticamente zero. O ponto fraco dessa abordagem é que você precisa manter uma tabela de mapeamento e o código fica menos legível para quem não está a trabalhar com enums. Também exige migração se o sistema já estiver em produção. Mas compensa quando o volume de dados é alto e a consistência é crítica — como em relatórios regulatórios ou integrações entre sistemas legados.

Resumo prático

Escolha uma grafia padrão — digestivo é a opção mais segura no contexto brasileiro. Normalise as entradas no back-end com replace ou regex. Valide no front-end com campos estruturados quando possível. Se o problema for grande escala, considere abandonar strings e adotar códigos. Teste sempre em staging antes de aplicar em produção. E leve um backup junto, não subestime o risco de um update mal calibrado. Isso é tudo que preciso dizer sobre o tema. Se você tiver um cenário específico em mente — seja integração com API, migração de legado ou algo do tipo — posso detalhar a abordagem que melhor se encaixa no seu caso.