0

客户站点提供了以下提取文件供我们加载到我们的数据库中。

问题是，对于某些行（例如第二行），CREATED_DATE 和 LAST_UPDATE_DATE 采用“dd Mmm YYYY...”日期格式，而其余行（例如顶部）采用“YYYY- MM-DD HH24.MI.SSXFF"

PRIMARY_ID  ID VALUE       CREATED_DATE          LAST_UPDATE_DATE
20166267    20834830491    2012-04-30 08:18:00   2012-04-30 08:18:00
20166536    9112           01 Oct 2010 17:27:04  01 Oct 2010 17:27:04

我的问题是：Q1。为了避免必须请求提取，我们可以在导入时使用 .ctl 脚本在 SQL 加载器中处理这些“dd Mmm YYYY...”格式的日期吗？目前我的 .ctl 是

我的 .ctl 文件被编写为使用以下脚本导入：

IDENTIFIER_START_DATE   TIMESTAMP "YYYY-MM-DD HH24.MI.SSXFF",
LAST_UPDATE_DATE        TIMESTAMP "YYYY-MM-DD HH24.MI.SSXFF"

Q2。只是要求他们按照在这种情况下的最佳实践要求重新提取所有日期格式吗？

4

2 回答 2

2

是否请求重新提取数据取决于许多因素。

  • 这是一次性过程还是持续的数据馈送？尝试使用一次性加载的数据尽最大努力可能是完全合理的，这样更容易观察异常值。如果您要管理持续的数据馈送，通常更有意义的是就文件的严格标准达成一致，而不是尝试手动检查有问题的行。
  • 客户是否有动力让您的加载过程简单且可重复？或者客户是否以固定价格出售，以他们想要提供的任何格式加载数据？如果客户有动力使加载过程简单且可重复，那么他们花时间生成干净的文件是有意义的。另一方面，如果您以固定价格向他们出售将文件转换为连贯数据所需的任何工作，那么如果您将大量工作推回给他们，他们可能不会高兴。
  • 是否存在数据不明确的行？例如，“01-02-03”可以指 2003 年 1 月 2 日或 1903 年 1 月 2 日或 2001 年 2 月 3 日或许多其他日期。如果有歧义，请求重新提取是有意义的。

至于如何加载数据，虽然可以一步完成，但您通常不希望这样做。通常将数据加载到登台表（或使用外部表）中更有意义，其中所有列都声明为VARCHAR2，然后编写一些 ETL 逻辑将数据转换为适当的数据类型（并记录数据的错误不能转换）。例如，如果您将数据加载到所有列都定义为 的临时表中VARCHAR2，您可以在此线程中使用类似 my_to_date 函数来尝试许多不同的格式掩码以找到一个有效的掩码（如果有很多对于可能的掩码，您可能希望遍历一个集合，而不是像我在那个示例中那样对两个掩码进行硬编码）。

另外一点...... OracleDATE将时间存储到秒，这似乎是您所获得数据的精度。因此，将数据加载到DATE列而不是TIMESTAMP列中似乎更有意义。

于 2013-03-07T00:09:09.917 回答
1

使用这个 .ctl 脚本： 

load data
append
into table schema_name.table_name
fields terminated by ';' optionally enclosed by '"'
(
PRIMARY_ID,
ID_VALUE,
CREATED_DATE "to_date(:CREATED_DATE, case when regexp_substr(:CREATED_DATE,'\w+',1,2)=regexp_substr(:CREATED_DATE,'\d+',1,2) then 'YYYY-MM-DD HH24:MI:SS' else 'dd Mon YYYY HH24:MI:SS' end)",
LAST_UPDATE_DATE "to_date(:LAST_UPDATE_DATE, case when regexp_substr(:LAST_UPDATE_DATE,'\w+',1,2)=regexp_substr(:LAST_UPDATE_DATE,'\d+',1,2) then 'YYYY-MM-DD HH24:MI:SS' else 'dd Mon YYYY HH24:MI:SS' end)"
)
于 2013-03-07T00:28:16.043 回答