ETL 工具适用于固定的，稳定的流程；
而SQL代码适用于个性化，独立，可变性比较大的情况！
ETL工具能做的事，SQL也都可以完成，反过说就不行了。
ETL工具的好处在于流程处理的标准化管理，以及任务调度的可视性、数据稽核过程的可视性等。
个人以为，对于工程项目，这两者将是共存的情况。 |
ETL工具显然有助于标准化。
好的DBA可以写出更优美精炼的语句，但是不利于维护和标准化。 |
第一要根据商务项目的规模，现在有些BI项目甲方规划的投入就很少了，如果再买第三方工具乙方根本就没钱赚了，一般这样的项目开发时候使用sql做etl过程的多，或者是乙方自己开发的etl工具，但是基本不能达到DS那样的水平。
第二在够大的BI项目或者甲方有ETL工具的投入时候才会采用，但是也要和sql结合使用。
第三要看etl逻辑的复杂度，一般的清洗工作etl工具使用比sql灵活简单，但是在复杂业务逻辑处理就不行了，例如有数据拆分，一条记录根据业务规则拆分几条，这样要涉及数值型小数保留位数，最后拆分后的几条记录合计值是否能保证和拆分前一致这样的问题都是存在的。 |
一些异构的数据库还是需要用ETL工具的吧。遇到需要把文本，MF数据，DB2,SQLServer, paradox的数据一起抽取到用oracle的warehouse中，似乎只有用ETL工具。
另外ETL在大型企业里的分工还是很细的，
做mapping,建workflow,做monitor，做数据处理都是由不同的team来完成的， 我之前的一个项目，老美负责做mapping,workflow.
中国这边只有monitor的权限，主要monitor ETL工具的装载速度和进度，如果遇到性能问题或者数据错误，就page DBA团队或者另外的团队来处理。
大公司对权限要求比较高，类似于这样的需求都必须通过ETL工具来实现的。 |
ETL工具相对于SQL的一个很大的优势在于代码的可维护性上
写SQL，取决于开发人员的经验与习惯，如原开发人员离职，由其他人接手任务的话，读懂之前开发人员的代码会花费较长的时间
但在复杂的数据处理中，还是应该用SQL来处理，嵌套在ETL工具中。
|
ETL 工具开发效率高、便于后期维护。SQL代码灵活，如果开发人员编码水平过硬，数据处理效率高 |
个人感觉吧大家轻喷， 从以前工作的中来总结出来一些东西吧
etl 和sql是完全不同的方面，
etl正如其名一样，当然大家也可以说elt 呼呼，更多的是清洗装载过程，当然你也可以说我可以直接用SQL创建呀，
etl更多的是一种方案，一个数据仓库上数据来源清洗加载的过程，拿我们以前举例，可以定制自己 的触发机制以及通过系统 的子线程 来分配任务运行机制，
当然你也可以用SQL+其它语言来解决 。
如果说不同的方面，我个人感觉SQL只是一种语言，一种操作数据的方式，而ETL更多的是一种方案，一种数据加工挖掘的方案。 |
认同大家的观点：
1. 工具容易规范化，易于维护；
2. 工具有自身的特有优势，比如各个点的并行处理。CDC、行列转换、SCD的简单设置就可实现。元数据管理等；
3. 工具能实现的基本SQL也能实现，有时可能要写复杂SQL而已；
4. SQL在处理复杂逻辑时灵活性更高，优势明细；
5. SQL的不易维护和管理。 |
sql（含存储过程）做转换清晰逻辑，开源etl做调度。 省成本。效率高。
“很多人认为用工具没有纯手工打造的人牛B，那是这些人根本就没把工具玩透”
非常赞同你的观点！
顺便说句：在打造企业级的应用平台时，是纯SQL无法企及的坎。
很多人理解ETL工具都狭义的理解为ETL任务设计管理工具了，
在我看来，ETL工具要分 ETL任务设计管理和ETL调度监控管理两个方面。
最近网上这个TASKCTL貌似火了，而且现在还开源了。
free的ETL调度平台 ＋ free的ETL任务设计(例如用kettle) = free的ETL解决方案，多好啊
二者互相补充，我一般是习惯于，复杂的业务逻辑由程序实现，调度和简单的业务逻辑由工具实现；
工具和代码都有各自的应用场景，比如工具在异构数据源之间的同步有优势，但适用于数据量不是很大的情况下；另工具的调度的功能也特别好，这样你就不用再写专门的程序来实现调度了，在工具基础层可以方便的进行二次开发设计，对异常情况可以较好的进行处理。 |
|
结构化数据，数据库引擎效率更高。
http://www.itpub.net/thread-1581786-1-1.html |
|