所以我大约 2 个月前学会了如何用 SQL 编码，所以我还是很新，每天还在学习不同的命令/函数。我的任务是将一些查询从 Teradata 迁移到 Redshift，显然存在一些不同的语法。现在我已经能够替换其中的大部分，但我被困在命令“SYS_CALENDAR”上。有人可以向我解释 SYS_CALENDAR 的工作原理，以便我可以对其进行硬编码，或者有人知道在 AWS Redshift 中运行的任何合适的替代品吗？
谢谢
【问题讨论】：
标签： sql amazon-web-services amazon-s3 amazon-redshift
作为已将大型 Teradata 解决方案移植到 Redshift 的人，让我祝你好运。这些是非常不同的系统，移植 SQL 以实现功能等效只是第一个挑战。如果您愿意，我很高兴就这些挑战可能是什么进行交流，但首先是您的问题。
Teradata 中的 SYS_CALENDAR 是一个系统视图，可以像保存每个日期信息的普通视图一样使用。这可以根据需要进行查询或连接，以获取例如有关日期的星期几或一年中的星期几信息。它确实根据操作系统信息执行日期计算功能，但使用起来像视图。
Redshift 中不存在等效视图，这造成了一些移植困难。许多人在 Redshift 中创建“DATES”表来保存他们在某个范围内的日期所需的信息，并且有关于制作此类表的网页（例如https://elliotchance.medium.com/building-a-date-dimension-table-in-redshift-6474a7130658）。只需预先计算数据库中日期范围所需的所有日期信息，即可在移植时将其交换为查询。这是最简单的移植途径，也是许多人选择的途径（有时是错误的）。
此路由的问题在于，用户支持的 DATES 表通常是一个等待引爆的定时炸弹和解决方案的技术债务。此表仅包含您在创建时指定的日期，并且日期范围通常会随着时间的推移而扩大。当它与不在 DATES 表中的日期一起使用时，会创建错误的答案，数据已损坏，并且通常是无声的。不好。一些创建流程来扩大日期范围，但这又是基于对如何使用表格的一些“预期”。它也是一个真实的表，其中包含不断扩展的数据，这些数据经常使用会导致潜在的查询性能问题并且并不是真正需要的 - 一直以来都是性能税。
更好的长期答案是使用本机 Redshift (Postgres) 日期函数根据需要对日期进行操作。这样做会使用操作系统对日期的理解（无限制），并执行 Teradata 对系统视图所做的事情（计算所需的信息）。例如，您可以使用 DATE_PART() 函数而不是加入 SYS_CALENDAR 视图来获取日期的工作周。这种方法没有 DATES 表的缺点，但会带来移植成本。查询的结构需要更改（删除连接和添加函数），这需要更多的工作并且需要了解原始查询。不幸的是，在移植数据库时，时间、工作和理解往往是供不应求的，这就是为什么 DATES 表方法经常被视为技术债务并永远存在的原因。
我假设这个端口本质上很大，如果是这样，我的建议是 - 为利益相关者安排这些权衡。如果他们不能花时间转换查询（可能）建议使用 DATES 表方法，但要清楚地记录技术债务以及功能将中断的“结束日期”。我会选择一个比较接近的日期，比如 2025 年，这样就需要对长期计划采取一些行动。记录何时需要采取行动的触发器。
这不会是此类港口出现的“技术债务”问题中的第一个。有太多地方“把它做好”会胜过“把它做好”。您甚至还没有触及性能问题的表面——随着时间的推移，这些是非常不同的数据库和数据解决方案，因为 Teradata 不会在基于简单端口的 Redshift 上实现最佳性能。这不是“全部丢失”级别的问题。只需记录选择以及这些选择的长期影响。为何时需要跟进“优化”工作的“端口”的各个方面定义触发器（日期或性能度量）。管理层喜欢忘记对这些工作进行后续跟进的必要性，因此请将这些记录在案。
【讨论】：