Salvar uma instrução SQL em uma tabela para execução posterior é uma má idéia?

Salvar uma instrução SQL em uma tabela MySQL para execução posterior é uma má idéia? As instruções SQL estarão prontas para execução, ou seja, não haverá parâmetros para trocar nem nada, por exemplo DELETE FROM users WHERE id=1.

Acho que estou sendo preguiçoso, mas pensei nessa idéia porque estou trabalhando em um projeto que exigirá alguns trabalhos cron que executam instruções SQL periodicamente.

É seguro, se é isso que você está perguntando. Contanto que você tenha tanto cuidado com sua segurança quanto com a segurança de seus dados.

Mas não reinvente a roda, procedimentos armazenados são bits de SQL armazenados em uma tabela. E eles apóiam, não encorajam, a parametrização.

Observe também que você pode simplificar sua segurança E reduzir o número de pontos de falha E reduzir as comunicações de rede usando o MySql Event Scheduler em vez de cron.

Outros bancos de dados têm equivalentes a esses, por um bom motivo. Você não é o primeiro a precisar dessa funcionalidade.

Se você deseja salvar instruções SQL em um banco de dados para execução posterior, há uma opção melhor do que colocá-las em uma tabela: use a funcionalidade interna fornecida para esse fim específico. Coloque-os em procedimentos armazenados.

Não, eu diria que não é uma boa ideia.

Isso significa que toda consulta / atualização "real" precisará de 2 ocorrências no banco de dados - uma para obter a consulta / atualização "real" e outra para executá-la.

Isso pode não ser um grande problema em um sistema pequeno, mas quanto mais usuários / transações o seu sistema obtiver, menos ele será dimensionado.

Acho que isso vem da procura de uma alternativa para incorporar SQL no seu código?

Encapsular o SQL em um procedimento armazenado, como sugeriu Mason Wheeler, seria uma maneira muito melhor do que essa idéia.

Desculpe, não acho que seja uma boa ideia.

Considere o caso em que a tabela em questão é alterada. Digamos que sua coluna de ID seja renomeada para new_id .

Além da alteração em si, existe uma versão do seu código escrita para um vintage antigo do banco de dados que pode não ser mais executado. Claro, talvez você deva verificar a tabela de códigos, mas isso não é imediatamente óbvio para outra pessoa.

Para uma mudança como eu descrevi, eu normalmente procurava arquivos SQL autônomos, procedimentos armazenados, gatilhos, SQL em linha no código do cliente (VB, C #, C ++ etc.), mas o último lugar que eu pensaria em procurar está nas tabelas de banco de dados. Embora talvez eu vá agora! :)

Existem motivos válidos para armazenar SQL em uma tabela. O software com o qual trabalho no trabalho agora inclui um sistema para gerar documentos e os documentos precisam incluir cálculos bastante complexos usando dados em um banco de dados. Os documentos são atualizados com freqüência, geralmente são significativamente diferentes em termos dos dados necessários e dos cálculos que precisam ser executados. O SQL está sendo usado, basicamente, como uma linguagem de script para executar esses cálculos e o SQL é armazenado em tabelas que também armazenam outras informações para esses documentos. As pessoas que mantêm esses documentos não são programadores ou DBAs, mas estão familiarizadas com o esquema do banco de dados e são proficientes em SQL. Seria uma sobrecarga significativa para eles manterem esse código SQL na forma de procedimentos armazenados.

Pelo que você descreveu - "... um projeto que exigirá algumas tarefas cron que executam instruções SQL periodicamente" - as outras respostas provavelmente estão corretas ao sugerir que você usou procedimentos de armazenamento, ou o equivalente, para o DBMS que você ' re usando.

Um bom critério para decidir se é sensato armazenar SQL em uma tabela versus em um procedimento armazenado é determinar quem manterá esse SQL. Se os usuários mantêm esse SQL, ou seja, eles o escrevem e o alteram sempre que desejam, pode ser perfeitamente bom e, na verdade, melhor armazenar esse SQL em uma tabela. Se os desenvolvedores mantiverem esse SQL, ele deverá ser armazenado em um formulário que possa ser atualizado pelos seus procedimentos de criação e implantação (esperançosamente automatizados), por exemplo, armazenados como um objeto, como um procedimento armazenado no próprio banco de dados.

A saída mais fácil seria ter um arquivo .ini ou outro arquivo de configuração para manter as consultas. Dessa forma, você pode tê-las em um só lugar, alterar qualquer coisa sem ter que acessar o banco de dados, não acessar o banco de dados várias vezes. e você também pode querer / precisar em algum momento usar parâmetros ou adicionar condições às suas consultas (aumente-as com itens mais complexos para um caso específico em seu código).

É claro que você pode mantê-los no nível do banco de dados (em uma tabela ou, melhor ainda, como procedimentos armazenados), no entanto, se você é tão preguiçoso quanto eu ;-) mas também se preocupa com desempenho, um arquivo .ini e PHP O amado método parse_ini para lê-lo, é o caminho a percorrer (se você estiver optando por outra linguagem de programação, estará descobrindo abordagens semelhantes)! Normalmente, eu lia esse arquivo no carregador de inicialização do aplicativo e o mantinha em um objeto estático (talvez com uma camada de cache na parte superior) para realmente acelerar as coisas se estivermos falando de um número muito grande de consultas distintas.

Se você precisar da instrução SQL apenas uma vez, por exemplo, se estiver enfileirando várias operações para executar fora do horário comercial, sim, colocá-las em uma tabela funcionará perfeitamente.

Se você precisar executar a mesma instrução SQL em intervalos especificados, a rota do procedimento armazenado que outras pessoas mencionaram provavelmente será uma escolha melhor para você.

Dito isto, o que você está perguntando é bastante incomum e pode ser uma indicação de algum outro problema. Por exemplo, se você estiver esperando para excluir um usuário de um banco de dados, talvez seja melhor chamar um script agendado que faça a operação através do código do aplicativo, em vez de gravar as instruções SQL reais. Dessa forma, o SQL e o código nunca estão fora de sincronia.