我遇到什麼，我認爲是Oracle怪異的行爲如果它有可能創建一個外鍵，其中列大小不匹配
它可以創建一個外鍵，其中列大小不匹配來參考列大小，這似乎是不正確的。當然，數據庫應該強制實現匹配的列大小，我在這裏錯過了什麼？
我確信MySQL沒有允許這個
SQL> create table parent(col1 varchar2(255) primary key);
Table created.
SQL> create table child(col1 varchar2(20) primary key, constraint col1_fk foreign key (col1)
references parent(col1));
Table created.
雖然它肯定是首選，如果FK兩種數據類型和大小相匹配，有可能是時候，它是不實際的（甚至一個好主意）。在你上面的情況中，PK更大，因此這不會導致數據輸入到第二個表中的問題，因爲它們只會輸入50個字符或更少的字符（在子表字段較大的情況下反過來將毫無意義你永遠不能輸入比PK更大的數據）。根據第一個表中的數據，實際上可能會阻止您輸入原始表中的值，而這些值並不是FK所希望的。但是，如果您想鏈接到長度爲118個字符的PK記錄，則會遇到問題。
讓我們來看看最初設計的表格的情況，該字段過於龐大，並且歷史上存在一些我們想要保留的數據，但不會鏈接到任何新表格中。也許我們現在通過觸發器或約束或通過應用程序來執行較小的大小。在新的子表中，我們只希望能夠加入符合當前需求的記錄，並且將永遠不需要加入較長的較長記錄。在這種情況下，設計第二張表只需要較小的長度是一個好主意。
還有一些情況，其中初始表可能包含不同類型的數據（稱爲鍵值存儲），子表可能只想鏈接到一種類型，並且該類型的長度小於父元素允許的長度表來說明不同的類型。再次使用較小的長度將是一件好事。
我會想象這種情況是爲什麼它被允許。但是，僅僅因爲允許某些東西並不是最佳做法。如果我正在創建一個表格，並且我沒有具體的理由說明該字段應該不同，那麼我會創建它們。它就像遊標一樣，它們存在於特定的用例中，但它們可以用於其他不是最佳選擇的其他用途。數據庫設計涉及知道如何確定最佳方法，而不僅僅依賴於事實可能的事實。
主鍵列大小較高，所以理論上它不應該產生任何問題。
但是，當條件是其他方式，如主鍵大小較小，會造成麻煩。
但最好的方法應該是相同的數據類型和大小。
我對此有點驚訝，但不是太多。這甚至可能是限制'parent'中的哪些行實際上可以被'child'引用的可愛方式。對我來說，更令人驚訝的是，錯配是相反的方式（「孩子長度更長」）。 –
有趣的問題。 – HLGEM