命名外鍵列
現在我聽說命名外鍵列的最佳做法是表名和欄位名（如果同一個表有多個外鍵，則可能是函式），例如引用使用者表id列的外鍵將是：
creatorUserId現在的問題是，現在我正在建構我的應用程序，並且為了開發速度，我將通過代理外鍵 (INT AUTO_INCREMENT) 引用所有內容。我真的不想在開發的早期就比在這種情況下更快的情況下進入整體，我寧願把這些東西留到最後（試圖防止過早的優化，我更感興趣的是在前面工作-此應用程序的末尾，然後是後端）。
話雖如此，我擔心的是如果我實際上想將一些外鍵從代理鍵更改為自然鍵（所有相關表都將同時具有）並且我使用列名，例如
creatorUserId我將不得不通過所有後端程式碼來進行更改，這個過程不會很愉快。
我正在考慮做一些只使用外鍵列的函式和表名的事情，例如：
creatorUser在這種情況下，如果我更改用於外鍵的列，後端程式碼更改會簡單得多，並且它們會少得多（如果您使用的是我的 ORM）。此外，由於代理鍵通常是數字而自然鍵通常是字母字元，因此僅通過查看值就應該相對容易知道正在使用哪個。
這會被認為是不好的做法嗎？
當存在多列外鍵關係時，名稱“creatorUser”會失敗。
與這裡的其他海報一樣，我強烈支持對同一屬性使用相同的列名，無論它位於哪個表中。
想像一張桌子，叫做“書”。如果主鍵是“ISBN”，那麼引用表中的外鍵應該是“ISBN”——而不是“BookID”或“BOOKISBNID”或“BookISBN”。
我對此類問題的參考是 Joe Celko 的 SQL 程式風格（數據管理系統中的 Morgan Kaufmann 系列）。
命名列，以便在它們出現的上下文中理解它們，即它們所在的表。
如果對每個表都這樣做，那麼關係將很明顯，因為每列將引用具有相似名稱的外部列。
如果相互引用的列沒有相似的名稱，請確保正確命名 FK，以便立即清楚列之間的關係是什麼。
在編寫 SQL 時，這一切最終看起來更具可讀性（例如：
table1.foo = table2.foo，而不是table1.foo = table2.table1foo）。