用户帐户表，盐和哈希表上的第三范式

如何解决用户帐户表，盐和哈希表上的第三范式

|| 我了解盐，哈希和所有用于密码的好东西的重要性。我的问题与关系数据库理论有关。我对第三范式的理解是，每个元素都必须提供有关密钥，整个密钥的事实，而除了密钥之外什么也没有（请帮助我Codd，谢谢Wikipedia）。因此，我正在查看一些表格，而我碰到了这一点。

-- Users
CREATE TABLE accounts(
    player_id mediumint NOT NULL AUTO_INCREMENT,-- Surrogate Key
    username VARCHAR(32) UNIQUE NOT NULL,-- True primary key
    salt char(29),-- Passwords are stored in bcrypt hash
    hash char(60),-- Salt + Hash stored
    created DATETIME,lastlogin DATETIME,PRIMARY KEY (player_id)
  ) ENGINE = InnoDB;

问题：此表是否为第三范式？我的理解是……“哈希”取决于player_id和盐。 IE：哈希->（用户名，盐）。我只是看不到拆分此表有任何真正的好处。但是我担心可能存在更新异常或看不到的东西。

解决方法

\“ Hash \”取决于player_id和盐。 IE：哈希->（用户名，盐）。那真是怪了。通常，哈希值是从salt和密码派生的。在那种情况下，由于密码本身未存储在任何地方，因此哈希确实提供了有关特定用户的其他基本信息。如果同时存储了哈希和密码，则哈希在功能上将取决于密码和盐（可能还有用户名）的组合。因此，同时存储哈希和密码将违反3NF以及使用哈希的整个目的。如果没有额外的密码输入（没有存储在任何地方），就不可能根据数据库中的任何其他信息来计算哈希值。否则，哈希将毫无用处。既然是这种情况，哈希列在功能上就不依赖于数据库中的任何其他数据，并且该表符合3NF。如果您的哈希与密码无关，即可以从其他列中计算出来，那么是的，您不需要将其存储在数据库中。 , 是的，这很正常，请勿拆分您的桌子 , 请不要分开桌子。该表为第三范式。据我所知，所有列都依赖于player_id，但需要注意的是，盐值依赖于例如用户名或player_id。