hashing – Why do sites store user data all in one user table? Why not separate with salted and hashed unique keys?

Say I’m a Big Company with a bunch of user data, including usernames, email addresses, and salted and hashed passwords. I recognize that I’m susceptible to attack in some way shape or form, despite everything that I’ve done to try to prevent an attacker from gaining access (phishing is stupidly effective, after all).

Suppose I want to separate a hacker from getting to more data. Would it not make more sense for me to set up one table with user data consisting of a unique identifier, their salted and hashed password, and any other relevant data, then create another table of email addresses that has two columns; the email address, and a unique key. However, that unique key is based on a salted and hashed version of the unique key from the original users table that can be replicated (assuming you know the salt and the algorithm used.)

Now, assuming someone enters maliciously, they will have to determine two sets of salts and hashes– one to decrypt the password, and one to decrypt which email address is associated with that username and password. Gaining the email addresses is still valuable for stuff like spam mail, but it’s now double the effort if someone wants to figure out how to log in as a user. This obviously is n