有沒有我們沒有任何主鍵的情況？

Question

我最近閱讀了一篇關於創建安全的php登錄系統的文章，它將逐步引導，現在這個問題問我爲什麼在這篇文章中login_attempts表中沒有主鍵。 這是我講的文章： this article

Create the "login_attempts" table: 
CREATE TABLE `secure_login`.`login_attempts` (
    `user_id` int(11) NOT NULL, 
    `time` VARCHAR(30) NOT NULL 
) ENGINE=InnoDB 

請轉到步驟4

創建一個表來存儲的登錄嘗試。

那麼這個問題是真的很明確，就像標題is.is有任何情況下，我們沒有任何主鍵？

Answer 1

是有，但你需要ATLEAST上User_ID列添加非唯一INDEX在桌子上查詢時提高性能。

ALTER TABLE login_attempts ADD INDEX idx_userID (User_ID) 

• When To Use Indexes In MySQL
• MySQL Query Optimization

Answer 2

那麼主鍵的一點是要提供一些價值，您可在對性能的唯一值索引數據。在你所擁有的情況下，可能會出現這樣的情況，即這兩列都不是唯一的。假設您的登錄是多線程的，那麼雖然很小，但有很多用戶具有相同的登錄名稱，因此將主鍵放在該名稱上顯然會拒絕某人或導致錯誤。如果您將主鍵放在user_id上，那麼您會拒絕同一用戶的多次嘗試。

在其他情況下，例如爲兩個外鍵之間的表創建多對多關係，您可能會做類似的操作。

免責聲明我敢肯定有人可以提供更強的解釋，但是這是我的理解。

Answer 3

默認情況下主鍵不是必需的 - 它取決於表的eache行必須是可識別的，例如，當它被用作其他表中的外鍵時。

在這個特定的情況下，我會說user_id就足夠了 - 但它應該被編入索引，因爲您很可能想使用該列進行選擇。

Answer 4

有很少的情況下，主鍵是不必要的。想象一下，如果你想刪除一個特定的行，你怎麼能刪除正確的行？兩次登錄嘗試同時插入兩個相同的行。

Answer 5

主鍵是一種數據庫管理工具，它已成爲保持數據庫註冊表中統一信息的支柱。但是，只要有一個清晰安全的機制來保持數據庫中所需的信息一致性，就可以省去它們表。在數據庫級別，您可以處理主鍵。但是在邏輯層面上，你必須有一個機制來幫助你區分不同的註冊管理機構，它本身就是一個主鍵的實用概念......基本上是這樣的：如果你需要有一致的信息，你永遠不能處理的PK，在邏輯層面上..

在我目前的工作中，我成爲了dba的GPS跟蹤系統，並且我發現所有信息都是在MySQL中分類的。我「按原樣」接受了這個項目，幾乎沒有文檔和起點，但是要完成許多任務。我的第一個想法是掃描數據庫模式。我發現所有的桌子都沒有PK ......甚至沒有接近Database Normalization Basics。這是一個沒有PK或FK的關係數據庫，但是它可以運行，爲數千個GPS設備提供服務。

當然，這DB模式是非常容易失敗，但信息是由公司保持溫和洽，在一個非常原始的方式..

所以...我選擇上重做DB模式和遷移所有信息都基於自動增量PK，約束和完整性觸發器，開發用於處理所有數據庫數據的MVC應用程序，並且我面臨着相當大的挑戰：我的第一個有史以來的專業項目。

作爲我個人經驗的結論。主鍵是保持信息一致性，真實性和組織性的標準指南。您可以隨時處理它們，但使用它們將爲您在設計和實施方面節省大量完全不必要的工作。