Banco de dados é, na prática, um repositório de variáveis globais

O texto de Sean Goedecke parte de uma provocação: linhas e registros de um banco de dados são, por definição, variáveis globais, porque qualquer parte do programa pode ler ou escrever neles. Os dois motivos clássicos para evitar globais são o envio implícito de dados entre partes distantes do código e o acoplamento (se um trecho depende de um valor, outro pode quebrá-lo). O autor argumenta que ambos valem para bancos de dados, e cita bugs comuns de quem assume algo errado sobre o formato de uma coluna, como suporte a UTF-8 de 4 bytes ou se ela aceita NULL.

Ele testa cinco explicações para os bancos escaparem da crítica: talvez apps com banco sejam mesmo bagunçados; as garantias ACID; o acesso mais explícito (é preciso uma conexão e uma função de consulta); a menor flexibilidade (só guardam dados); e o fato de a gente saber usá-los. Ele descarta o ACID, porque um mutex em volta de uma global não a tornaria aceitável. Considera mais convincentes a explicitude e as convenções de uso, e nota que ambas são contingentes, não inerentes. Uma base de código com convenções para globais poderia cumprir as mesmas condições. Ele não recomenda usar variáveis globais, e sim desconfiar de quem invoca "boas práticas" sem dar motivos concretos.

Para quem trabalha com back-end e dados, a leitura prática é olhar o banco como estado compartilhado que pede disciplina: tipos checados, usos limitados e acesso visível no código. O autor faz uma ressalva que dialoga com isso: ferramentas como o ActiveRecord, do Rails, podem tornar as consultas invisíveis e enfraquecer a vantagem da explicitude.