Não polua a tabela de opções do WordPress
Eu sou um fã de ciclos de lançamento curtos. Dependendo do projeto, a duração do ciclo varia, mas para muitos dos tipos de projetos em que trabalho, pretendo ter ciclos de lançamento de duas semanas.
Além disso, há momentos em que estou trabalhando em um projeto para alguém em que as variáveis ambientais são necessárias para que o código saiba se está sendo executado em desenvolvimento, preparação ou produção.
E isso pode ser alcançado de uma maneira diferente, dependendo das necessidades do projeto. Às vezes, um arquivo de configuração funcionará, às vezes as variáveis de string de consulta podem funcionar e outras vezes acho razoável armazenar uma configuração no banco de dados.
Mas, no que diz respeito ao WordPress, acho que abreviamos melhores decisões de design e lançamos informações no banco de dados, especificamente na tabela de opções, quando as alternativas podem ser mais adequadas.
A tabela de opções do WordPress
Quero ser claro: não acho que a tabela de opções deva servir como lixeira para configurações quando você não tem mais onde colocar informações. E essa é a essência de todo este post.
Em vez disso, você pode usar:
- um arquivo de configuração,
- dados da sessão (quando apropriado),
- uma tabela de banco de dados personalizada,
- ou alguma outra coisa.
Então, por que vemos isso acontecendo com tanta frequência? Não é que não haja momentos em que faça sentido usá-lo. Só acho que abusamos. Mas há razões para isso.
O WordPress Codex define opções como esta:
Opções são pedaços de dados que o WordPress usa para armazenar várias preferências e configurações.
Com uma definição como essa, é fácil ver por que tantos a usarão como um lugar para guardar qualquer coisa que não cabe em nenhum outro lugar.
Em vez disso, acho importante fazer a pergunta:
Para que tipo de armazenamento [esses dados] são mais relevantes?
Ou seja, se está relacionado a postagens, por que não armazená-lo na meta tabela de postagens? O mesmo para metadados de termos ou comentários ou qualquer outra coisa.
O ponto é este:
Encontre o local mais lógico para armazenar os dados e coloque-os lá.
Em outras palavras, não jogue dados na tabela de opções do WordPress porque não cabe em nenhum outro lugar. Isso o polui. Em vez disso, encontre – ou crie – o lugar mais lógico para isso. Isso provavelmente é evidência de um cheiro de código e seria um bom motivo para reavaliar a arquitetura do seu código e como as informações estão sendo representadas.
Mas o que isso pode parecer? Ou seja, como pegaríamos um determinado pedaço de código e mudaríamos como ele é representado no banco de dados.
Infelizmente, é difícil fornecer uma solução prescritiva para essa questão sempre que existem tantas variações da implementação de um problema. Então, talvez uma diretriz simples esteja em ordem:
Se os dados estiverem relacionados aos tipos de dados (ou tabelas) pré-existentes, use-os; caso contrário, considere um arquivo de configuração ou uma tabela de banco de dados personalizada que mapeie para seu trabalho.
Tenho certeza de que existem outros fatores orientadores, mas este é um lugar melhor para começar do que simplesmente poluir a tabela de opções do WordPress.