什么提供更高的性能？
使用T-SQL编写查询，连接表，然后将结果插入另一个表
使用Pentaho Spoon的表插入，然后使用数据库查找＆＃34;加入＆＃34;每个表一次，然后将结果插入另一个表
目标是采用非规范化表格，通过其文本将其与5维表格连接，并检索维度＆＃39; PK，然后将结果插入事实表。
答案 0 :(得分：1)
可能更适合dba.stackexchange.com。但我想数据库引擎将更快地执行此任务，因为a）它可以使用索引和表统计信息优化对所涉及的所有表的访问，以及b）您可以摆脱ETL工具和多个数据库查询引入的开销。 Pentaho PDI单独处理行，因此对于来自表输入步骤的每一行，您将在每个查找步骤中都有一个SQL查询。
答案 1 :(得分：0)
认为SQL在复杂查询上优于Pentaho PDI是一种传统观念。真实性来自盲人认为SQL优化器给出了真正的最优化。
我有一些反例，通过将SQL查询复杂度提取到一系列查找和过滤器中，我们将查询时间缩短了一个多小时到几分钟。
我们更好，因为：
查找需要每个条目一个匹配记录，而SQL优化器必须假设连接不是唯一的。就像这里展开明星/雪花模式一样。
查找步骤非常智能，仅读取所需数据并将其保留在内存中，使用内部排序哈希表进行配置，以加快即将进行的查询。
当已知流程被分类时，上述特别有效。虽然select from oneTable order by很快，特别是当表被适当地编入索引时，相同的select from manyJoinedTables where LotsOfConditions order by可能效率很低，因为SQL不能指望索引。
事实上，我猜上述条件正是SQL优化器希望查找和依赖的条件，但由于一般性而无法实现。
根据经验，对PDI的效率充满信心。 Matt Casters和Jens Bleuel制作了一款非常好的软件，在大多数情况下进行了测试，你甚至无法想象。
因此，使用更容易维护的解决方案（大部分时间是PDI查找），如果它真的非常慢，那么将其移至Input Table但不要期望系统性更好。< / p>
注意：
避免Database Lookup（预准备语句使用缓存，但我们正是在每次查找不同密钥的情况下）。
避免使用Joins，即：明确告诉水壶它可以指望一个独特的匹配，如果你知道的话。 Join Rows和Merge Join是有效的步骤，但仅限于传入流的排序。
尽快使用Filters（减少行数）。甚至，每个规则都有它的例外，在SQL中。
不要费心减少Select values的列数。它对速度几乎没有影响！你没有东西Kettle天真地重复一步一步的值，而不是使用一个聪明的指针系统，不是吗？
与JavaScript的计算效果并不像图例所说的那么低效，事实上PDI通常在排序和查找方面更加繁忙。
不要在多个Memory Group by步骤中传播聚合。这些步骤中的每一步都需要在知道它完成之前读取所有传入流，因此它是下一步的阻塞因素。
通常Sorted Group by不会改善Memory Group by。一个例外是当内存达到其配额并且java开始在垃圾收集器上启动垃圾收集器时。在这种情况下，可以使用排序将数据存储在临时磁盘上。
避免使用中间表。而是通过添加列来构建流，并在数据准备就绪时将其抛入具有大提交大小的Output Table。