我已经围绕ETL做了大量的开发工作,并且我得出结论,ETL的最佳方法是声明式的(支持定制的命令式块/函数)。特别是,声明性方法允许对转换进行可视化,这可以使与业务/领域专家讨论转换变得更加容易。另外,不可忽视的事实是,声明性方法通常更紧凑,更易于维护。
不幸的是,我所见过的唯一一个半途而废的声明式转换语言/框架是XSLT。而且XSLT可能是可怕的,因为有很多其他的无关的原因。(特别是,在任何中等规模的转换项目中,它的冗长都会让人感到痛苦。)
XSLT真的是唯一或最好的声明式转换游戏吗?
我今天做了一些研究,而我发现的唯一替代方案似乎基本上是放弃了:
任何关于选项或分享智慧的建议都将不胜感激!
发布于 2017-07-27 08:33:44
您可以看到最新的信息这里。但是他们目前致力于提高他们的执行引擎的性能。ATL主要是一种受QVTr启发的声明式语言。
QVTr并没有完全死掉,Eclipse QVTd 项目正在积极地提供QVTr执行引擎。我不确定他们最终是否会支持可视化语法的编辑器。如果他们这样做了,我认为他们的计划是支持UMLX。
正如您所指出的,ETL是混合的,但这并不意味着您必须编写混合ETL脚本。一个纯声明性脚本将工作,ETL引擎将能够执行它。
IMHO、ATL和ETL都不仅仅是体面的声明式转换语言。
关于可视化语法,我建议您可以使用自己的符号,并使用天狼星来支持编辑器。在那里,您可以使用模型转换来生成等效的ETL/ATL代码,然后运行该代码:) (要么从模型到模型创建AST,要么从模型到代码生成脚本)。定义自己的可视化语法的好处是,您可以定制它以适应您的受众,确保它帮助您与他们讨论转换。
发布于 2017-02-20 11:02:46
我还发现声明式方法非常有效(正如我在一篇文章这里中解释的那样)。我这么说是因为我在过去10年中一直在维护基于代码的声明式ETL,第一次使用现在没有维护的活动仓库-etl,从2015年开始使用我编写和开源的Kiba ETL。
我确信其他基于声明性代码的ETL也存在!
https://stackoverflow.com/questions/42281485
复制相似问题