Una buona idea per spostare la logica dalle istruzioni SQL?

Un grande vantaggio di spostare il codice di elaborazione dal tuo SQL è che il tuo SQL diventa molto più semplice da gestire.

Uno svantaggio è che se si desidera utilizzare tali query in qualche altro programma, è ora necessario rendere disponibili i processi di elaborazione dei risultati all'altro programma. Potrebbe essere semplice come copiare un file di libreria che contiene le classi necessarie, ma significa comunque che tutte le modifiche alla libreria devono essere propagate e tutti i client ricostruiti con la nuova libreria.

Un'altra opzione: perché non utilizzare una vista (o più viste se hai bisogno di risultati formattati in modo diverso per client diversi) per contenere la maggior parte del codice di formattazione? In questo modo puoi ottenere i risultati della query "grezzi" o quelli con una formattazione gradevole, a seconda di cosa ti serve.

Sono d'accordo con il suggerimento già fatto sull'utilizzo di una vista per questa logica. Vorrei solo aggiungere un'altra cosa sulle affermazioni Case. Tenere presente che estrarre le dichiarazioni del caso dall'SQL potrebbe comportare un impatto significativo sulle prestazioni del sistema. Queste affermazioni Case potrebbero ridurre significativamente la quantità di dati restituiti. L'esecuzione del filtro Case nel livello database tramite istruzioni SQL è in genere molto più efficiente rispetto al recupero di tutti i dati e al filtraggio in uno script o programma esterno. Se stai considerando questo, ti consiglio vivamente di eseguire alcune analisi dei dati e test delle prestazioni prima di procedere con quella soluzione.

L'aggiunta di un processo esterno di solito rende il sistema più difficile da eseguire il debug, ma in realtà dipende dalla situazione. Usa il tuo giudizio . Considera il tempo necessario per sviluppare / mantenere progetti fuori banda.

Stai già utilizzando un processo ETL ? Non ho esperienza con Teradata, ma separare i tuoi passaggi fornisce una visione molto più chiara di ciò che sta accadendo. Ecco una panoramica di 2 secondi:

1. Estrai: estrai i tuoi dati dall'origine e inseriscili nella memoria temporanea di Stage 1. Non modificare il formato dei dati.
2. Trasforma: tira dalla fase 1, e fai tutto il caso / assetto / substr / cast / formattazione ecc ... che hai bisogno qui. Inseriscilo nella memoria temporanea stage 2.
3. Carica: estrai dalla fase 2 e inserisci tutti i dati nella memoria di destinazione.

Questo di solito fornisce informazioni sufficienti per gestire con successo questo tipo di sistema.

Sarei propenso a lasciare in posizione i bit CASE poiché questi sono correlati alla logica effettiva di produzione dei dati per somone / cosa da consumare. Quindi toglierli vuol dire che devi inviare un set di dati più grande e il client deve elaborarli su di esso - ora hai diviso il tuo rapporto "logico" su due livelli separati e questo non va bene.

Ma vorrei rilasciare come un mattone caldo qualsiasi formattazione dal tuo codice (a meno che non sia specificamente parte dei predicati JOIN, ecc.) perché la formattazione è il lavoro del consumatore ... quindi qualsiasi strumento di segnalazione che usano, sia Excel, Crystal , ecc., è bravo a formattare le cose nel locale corretto e tutto quel jazz. Lascia che il client faccia ciò che è buono (mostrando le cose con bei colori) e lascia che il server si concentri su ciò che sa fare meglio - scricchiolare i dati.