Teradata如何处理外键？

Question

我正在开始一个新项目，其中一个要求是使用Teradata。我精通许多不同的数据库系统，但Teradata对我来说还是个新手。

在客户端，他们根据“顾问”的建议从他们的数据库中删除了所有外键。

我的每个部分都在畏缩。

我正在使用一个新的数据库实例，因此我不会受到他们在其他数据库上已经完成的操作的限制。我没有被明确告知不要使用外键，而且我与客户的关系是这样的，他们至少会听我说。但是，我的决定和案例应该是明智的。

是否存在任何内在的技术原因，我不应该在Teradata中使用FK来维护基于Teradata设计，性能，副作用等的参照完整性......

值得注意的是，我正在使用.Net Data Provider v16访问Teradata，该版本仅支持EF5。

Answer 1

假设新项目正在实施数据仓库，原因很简单（对于任何DWH都是如此，不仅仅是Teradata）：DWH与OLTP系统不同。

当然你还有小学和初级逻辑数据模型中的外键，但可能未在物理模型中实现（尽管Teradata支持它们）。有几个原因：

• 数据通常分批加载到DWH和PK＆amp;在插入/更新/删除之前，必须通过加载过程验证FK。否则，您加载1,000,000行，并且单行未通过约束。现在你有一个Rollback和一条错误消息，并尝试找到不良数据，祝你好运。但是当在加载期间已经完成所有验证时，没有理由在数据库中第二次进行相同的检查。
• DWH中的某些表将是慢慢改变维度，并且无法在该usibg标准SQL合成器上定义PK / FK，您需要类似 TableA.column引用TableB.column和TableA的内容TableB.ValidFrom和TableB.ValidTo之间的.Timestamp （创建临时表时可以）
• 有时会从头开始重新创建或重新加载表格，如果有FK引用它则很难做到。
• 有些PK从不用于任何访问/加入，所以为什么要在物理上实现它们，这只是CPU / IO /存储的巨大开销。

关于PK / FK的知识对优化器很重要，因此有一个所谓的 Soft Foreign Key （REFERENCES WITH NO CHECK OPTION），这是一种虚拟：应用于优化，但从未实际由DBMS检查（它告诉优化器信任我，它是正确的）。