我收到的用于例行刷新的数据集包含一个实际上是VARCHAR的日期字段。
由于这将是一个索引/搜索字段，我只剩下
1） 将字段转换为DATETIME，并在刷新时验证和规范数据值
或者
2） 保持数据原样并形成我的查询以适应各种有效的日期格式。，其中DateField='CCYYMMDD'或DateField='MM/DD/CYY'或。。。。
每月更新一次；"清理"数据将为ETL周期增加大约35%的时间。我对日期字段的查询都是相等的；我不需要进行范围搜索。此外，我是一个人的商店，所以整体解决方案越简单越好。
那么，我在哪种情况下做得更好呢？感谢所有意见。
我认为这是一个很好的问题。以下是我的看法：
我非常相信这样一种观点，即从长远来看，通过将数据类型用于预期目的，可以节省更多时间，减少麻烦。这意味着日期字段中的日期、字符字段中的字符等。如果选择选项2，则每次查询表时都需要记住为所有可能的日期格式编码。如果你把这件事记下来，一年后回来，你会记得吗？
相比之下，如果您使用日期字段，并在ETL过程中正确处理日期的前期工作，您将始终知道如何与该字段交互。我甚至不打算讨论性能影响。
在这种情况下，我不确定你是否会看到短期的好处。例如，如果源数据中有5种不同的可能日期格式，您需要以某种方式说明这些格式；无论是在ETL中还是在输出查询中。在ETL中转换这5种格式的代码并不比在输出查询中管理这5种形式的代码复杂。
如果数据可以以无限的格式到达，那么无论哪种方式，都会遇到大问题。要么ETL会中断，要么查询会中断。在某种程度上，这是一种不可简化的复杂性。
我建议您花点时间将适当的转换编码到ETL中。但帮自己一个忙，编写一个预处理步骤，以无法正确转换的格式识别日期并提醒您。如果你看到图案；也就是说，如果任何格式出现不止一次，请为其编写转换代码。随着时间的推移，你将手动清理越来越少的讨厌的日期。运气好的话，你的35%会降到5%或更低。
祝你好运！
您最好清理数据。不好的第一次约会是没有意义的，所以储存它们也没有意义。其次，以后修复一个错误的数据类型选择比永远不做更难。查询不仅更容易，而且比使用varchar更快。像排序这样的功能以及日期函数都能正常工作。第三，我无法想象清理它会给你的导入增加那么多，我一直在清理数据而不会有问题。但如果是这样，那么就清理一个没有其他进程使用的暂存表中的数据（这样就不会影响prod上的用户），然后从干净的数据加载到prod表。
提前清理数据并将日期存储为日期。
我使用的系统将日期存储为字符串，并且似乎有无限多的方法来存储日期。这使得创建一个查询非常困难，该查询将针对未来的新日期格式工作。
如果将日期存储为字符串，则应应用约束以确保数据以正确的格式存储。或者，只需将日期字符串转换为日期，并让数据库本身应用有效的日期约束。通常最好让数据库为您完成工作。
最好清理数据并加载到日期列中，因为这将确保完整性。