Teradata如何處理外鍵？

Question

我正在開始一個新項目，其中一個要求是使用Teradata。我精通許多不同的數據庫系統，但Teradata對我來說是相當新的。

在客戶端他們已在「顧問」的建議，刪除從他們的數據庫中所有外鍵。

我的每一個部分都是c。。

我使用了一個新的數據庫實例，所以我沒有什麼，他們已經在其他數據庫進行限制。我沒有明確地告訴我不要使用外鍵，並且我與客戶的關係是這樣的，他們至少會聽我說。但是，我的決定和案例應該是消息靈通的。

有沒有，我不應該使用FKS在Teradata數據保持基於Teradata的設計，性能，副作用等參照完整性的任何內在的，技術的原因...

值得注意的是，我訪問的Teradata使用僅支持EF5的.Net Data Provider v16。

Answer 1

假設新項目正在實施數據倉庫有一個簡單的理由（這是真的對任何DWH，不僅Teradata的）：一個DWH是不一樣的OLTP系統。

當然，您仍然在邏輯數據模型中獲得了主鍵&，但可能沒有在物理模型中實現（雖然它們受Teradata支持）。有幾個原因：

• 數據通常裝載分批進入一個DWH兩者PK & FKS必須加載過程進行驗證，然後插入/更新/刪除。否則，你加載1,000,000行，並有一行失敗的約束。現在您收到了回滾和錯誤消息，並嘗試查找不良數據，祝您好運。但是當所有驗證都在加載期間完成時，沒有理由在數據庫中第二次執行相同的檢查。
• DWH中的某些表格將變慢速度並且無法在該usibg標準SQL合成器上定義PK/FK，您需要類似於表Table.column引用TableB.column和TableA.Timestamp TableB.ValidFrom和TableB.ValidTo（這是可能的，當你創建態表）
• 有時一個表或重新從頭開始重新加載，很難做，如果有一個FK引用它。
• 一些的PK永遠不會用於任何接入/加盟，那麼爲什麼物理實現它們，它只是在CPU/IO /存儲一個巨大的開銷。

知識約PK/FK是優化很重要，所以有所謂軟外鍵（REFERENCES WITH NO CHECK OPTION），這是一種假：優化過程中應用，但實際上從未由DBMS檢查（這就像告訴優化者相信我，這是正確的）。