Boa idéia para mover a lógica das instruções SQL?

Eu prefácio essa pergunta dizendo que sou muito novo no desenvolvimento de software profissional.

Eu trabalho em uma equipe que coleta dados de outros grupos da minha empresa e transforma esses dados em relatórios utilizáveis ​​por executivos de negócios.

No processo de transferência e análise de dados, temos algumas instruções SQL que processam muito os dados. Quase todos os SELECTusos TRIM, etc SUBSTR, são CASTextensivos para reduzir os campos ao tamanho e formato adequados. Além disso, há muitos casos especiais que são contabilizados usando CASEinstruções dentro de SELECT's.

O software do servidor Teradata que usamos emite mensagens de erro notavelmente enigmáticas. Como resultado, fazemos muitas adivinhações sobre quais dados estão quebrando qual instrução SQL.

Minha pergunta é: seria uma boa idéia reduzir essas instruções SQL um tanto complexas para uma forma menos complexa que omita o processamento e o tratamento especial de casos e, em vez disso, isso funciona em um script ou programa externo? Isto faz algum sentido?

Uma grande vantagem de mover o código de processamento para fora do seu SQL é que ele se torna muito mais simples de gerenciar.

Uma desvantagem é que, se você quiser usar essas consultas em algum outro programa, agora precisará disponibilizar seus processos de processamento de resultados para outro programa. Pode ser tão simples quanto copiar um arquivo de biblioteca que contém as classes necessárias, mas ainda significa que quaisquer alterações na biblioteca precisam ser propagadas e todos os clientes reconstruídos com a nova biblioteca.

Outra opção: por que não usar uma visualização (ou várias visualizações, se você precisar de resultados formatados de maneira diferente para clientes diferentes) para conter a maior parte do código de formatação? Dessa forma, você pode obter os resultados da consulta "bruta" ou o bem formatado, dependendo do que você precisa.

Concordo com a sugestão já feita sobre o uso de uma View para essa lógica. Gostaria apenas de acrescentar mais uma coisa sobre as declarações Case. Esteja ciente de que retirar as instruções Case do SQL pode resultar em um impacto significativo no desempenho do sistema. Essas instruções de caso podem estar reduzindo significativamente a quantidade de dados retornados. Executar a filtragem de caso na camada de banco de dados por meio de instruções SQL é normalmente muito mais eficiente do que recuperar todos os dados e fazer a filtragem em um script ou programa externo. Se você está considerando isso, eu recomendo fazer algumas análises de dados e testes de desempenho antes de avançar com essa solução.

Adicionar um processo externo geralmente dificulta a depuração do sistema, mas isso realmente depende da situação. Use seu julgamento . Considere o tempo necessário para desenvolver / manter projetos fora da banda.

Você já está usando um processo ETL ? Não tenho experiência com o Teradata, mas separar suas etapas fornece uma visão muito mais clara do que está acontecendo. Aqui está uma visão geral de 2 segundos:

1. Extrair: retire seus dados da fonte e coloque-os no armazenamento temporário do estágio 1. Não altere o formato dos dados.
2. Transformação: Puxe do estágio 1 e faça todos os casos / trim / substr / cast / formatation etc ... que você precisa aqui. Coloque-o no armazenamento temporário do estágio 2.
3. Carregar: Puxe do estágio 2 e coloque todos os dados no armazenamento de destino.

Isso geralmente fornece informações suficientes para gerenciar com êxito esse tipo de sistema.

Eu estaria inclinado a deixar os bits CASE no lugar, pois eles estão relacionados à lógica real de produzir os dados para que alguém / coisa consuma. Portanto, removê-los significa que você deve enviar um conjunto de dados maior de volta e o cliente precisa fazer algum processamento - agora você dividiu a "lógica" do relatório em duas camadas separadas e isso não é bom.

Mas eu gostaria de remover qualquer formatação do seu código (a menos que seja especificamente parte dos predicados JOIN, etc.) porque formatar é o trabalho do consumidor ... portanto, qualquer ferramenta de relatório que eles usem, seja Excel, Crystal, etc. é bom em formatar coisas no local correto e todo esse jazz. Deixe o cliente fazer o que é bom (mostrando as coisas com cores bonitas) e deixe o servidor se concentrar no que faz melhor - processar dados.