C'est presque une question de sémantique. Beaucoup d'air chaud est libéré dans les discussions à ce sujet, mais je ne suis pas vraiment convaincu qu'il existe une réelle profondeur philosophique à une distinction entre les deux.
À un certain niveau, vous pouvez voir ETL comme transformant des données dans un outil côté client avant de finalement le charger, ELT impliquant que les données sont transférées vers une sorte de zone de transit avec relativement peu de changement de format. La «transformation» a lieu ensuite.
Ce sont des définitions très moelleuses et pourraient être appliquées à une grande variété d'architectures techniques, et il existe de nombreuses conceptions possibles que l'un ou l'autre terme pourrait être utilisé pour décrire.
Je suis très fortement en faveur d'une architecture où toute la logique de transformation et métier peut être intégrée dans une base de code plus ou moins homogène, et j'ai fait beaucoup de systèmes où la logique de transformation était assez complexe. Cela avait tendance à simplement utiliser l'outil ETL pour atterrir les données, puis toute la transformation a été effectuée dans des procédures stockées. On pourrait dire que cela pourrait être décrit comme ETL ou ELT, la différence étant simplement une question de sémantique.
Cependant, certains outils sont très centrés sur les bases de données (Oracle Data Integrator, par exemple, est souvent appelé outil ELT). Si vous vous abonnez à cette vue, alors «Extraire» et «Charger» se produisent avant que les données ne soient transformées lors de leur atterrissage dans une zone de transit, puis compressées par du code SQL ou PL / SQL (qui peut être généré par l'outil ou manuscrite). Plusieurs personnes à qui j'ai parlé semblent considérer le principal mérite de l'ODI car ce n'est pas OWB.
Si vous utilisez un outil côté client tel qu'Informatica Powercentre ou MS SQL Server Integration Services, l'outil peut effectuer une transformation approfondie du côté client des données. Certains outils ETL, tels que Ascential Datastage et Ab Initio sont conçus pour effectuer beaucoup de travail avec des fichiers plats et des structures de données en mémoire pour plus de vitesse. Dans ce type d'architecture, la transformation a déjà été effectuée avant son chargement. Peut-être que ce type d'architecture pourrait être définitivement classé comme «ETL», même si j'ai vu de nombreux projets axés sur les outils où tout le travail réel est effectué par un tas de code de procédure stockée.
Il y a des avantages à divers outils et approches architecturales, mais on ne peut pas faire une déclaration générale sur les mérites des approches 'ETL' contre 'ELT' parce que les termes sont si larges que la différence n'a presque aucun sens. Certains outils et architectures peuvent avoir des avantages spécifiques - par exemple, l'utilisation intensive de fichiers plats par Ab Initio lui confère un avantage de performances significatif sur de gros volumes de données.
En pratique, faire la distinction entre «ETL» et «ELT» n'a pas de sens sans entrer dans une discussion beaucoup plus approfondie sur les exigences du système, la plate-forme et l'architecture technique.