分期
我怀疑大多数环境将“ETL/staging”作为一个单独的步骤的原因是因为这两个端点有些僵化并且没有用于数据操作的良好编程语言。也就是说,如果您有 TXT、CSV、XML、JSON 或 SQL,并且需要其他格式/架构,那么必须有人进行“转换”。但是如果你在 GemStone 中工作,那么你可以在 Smalltalk 中进行转换——不需要单独的步骤。
文件
如果您有文件(TXT、CSV、XML、JSON 等),请使用GsFile。事实上,如果另一个端点可以处理文件,那么只需从一个源以约定的格式导出,然后导入另一个源(GemStone 进行“繁重的转换”)。文件更简单,它们避免了通信层,并且它们使调试变得微不足道(如果源没有创建文件,那么是源的问题;如果它在挂起的目录中,那么还没有处理它(目标问题); 如果它在已完成的目录中,则目标已处理它)。
使用这种方法,您可以在 GemStone 中启动(一个或多个)后台作业来监视目录、打开文件进行读取、处理文件,然后将其移动到另一个目录。除了基本的字符串操作,您只需要使用 GsFile。然后您在数据库中创建和更新您的对象。
ODBC
虽然可以从 GemStone 对 ODBC 库(或使用 GemConnect 对数据库的本机库进行 FFI 调用)进行 FFI 调用,但这可能会不必要地复杂。相反,我会使用与外部系统有更好交互的工具创建另一个层。该层可以编写文本文件(如上所述),或者,通过适当的接口,可以直接与 GemStone 通信。我倾向于使用 Dolphin 来提取数据(良好的 ODBC 支持),然后直接从 Dolphin 与 GemStone 通信。您可以使用其他客户端 Smalltalk 方言(Pharo、VA 或 VW)甚至其他语言(我有一个学生正在研究 GemStone 的 Python 接口)做类似的事情。
O/R 映射
在这里,您再次需要一种方法来获取一种格式的数据并将其转换为另一种格式。这些往往是高度特定于领域的,我们发现只编写 Smalltalk 代码更容易。或者,您可以在 Pharo、VA、VW 等中使用GLORP 之类的东西。
最佳实践
我认为您没有在 GemStone 中找到任何 ETL 的“最佳实践”,因为我们认为它不是一个外部过程或单独的步骤。只是如何与文件 (GsFile)、套接字 (GsSocket)、库 (CLibrary) 或客户端 (GCI) 进行通信。从这里我们可以看到内部处理问题,例如多个生产者和一个消费者(RcQueue),或一个生产者和多个消费者(锁定)。
因此,并不是 GemStone 应用程序不执行 ETL,它们只是在内部执行,而且情况更加针对特定情况。