问如何使用面向对象的Perl组装SQL？

EN

我目前负责一个似乎与数据库非常亲密的过程。我的程序/脚本/框架的目标是使不同数据源的一致性。使用依赖注入的一种形式，我的过程在一个非常高的层次上工作良好。每种数据源类型的实现都隐藏在最高级别的业务抽象中。太棒了。我的问题有两个。

1)我有一个很长的段落(困扰我的是长度)，它将Perl空间中的SQL语句组装在一起，说明如何将这些不同的数据源转换成一种同构的结束格式。所以SQL字符串总是取决于我正在处理的数据的类型。WHERE子句依赖，FROM子句依赖，INSERT子句依赖，这都取决于。正是这种高度的依赖-让我感到困惑。如何以面向对象的方式对此过程进行建模？>buildSQL？这基本上就是我现在所拥有的，但感觉上代码的所有部分都知道得太多了，因此它很长。

2)如果我有一个函数做某事(构建SQL?)，我是否将整个业务对象传递给它，然后在最后一刻对它们进行压缩？或者，我是否过早地将它们串起来，只让我的函数处理它需要的东西，而不是呈现对象本身？

编辑：虽然我不怀疑ORM的重要性，但我认为我们还没有进入ORM领域。想象一下，美国、国家和虚拟联盟的棒球数据都以极不相同的格式存储，而且标准化程度也不同。我的工作是读取这些数据源，并将它们放在一个统一的、规范化的池中。我觉得ORM空间对这些物体的作用发生在我的过程之后。如果你愿意的话，我是个数据管理员。实际上，由于缺乏我创建的统一池，还没有任何业务对象可供操作。

编辑^2：引起我注意的是，也许我还没有足够详细地描述问题空间。下面是一个例子。

想象一下你必须建立一个美国所有罪犯的主数据库。贵公司的服务是销售一种产品，该产品位于顶部，以干净、统一的格式提供对这些数据的访问。

这些数据是由50个州公开提供的，但格式却大不相同。有些是一个数据文件，而不是标准化的。其他是CSV格式的规范化表。有些是Excel文档。有些是TSV。有些记录甚至在没有手动干预的情况下是不完整的(其他手工创建的数据源)。

我的项目的目的是为50个州中的每个州建立一个“驱动程序”，并确保该过程的最终产品是一个完美的关系模型中的罪犯主数据库。所有的键都正确，图式的形状完美，等等。