I am with you on the theoretical aspects of this discussion but I have a hard time wrapping my head around the practical application aspects. In this example how would you model the primary key in the parent-table that stores people from which most people-attribute tables might be related? Assuming email is stored as a CHAR(320) and password is stored as a one-way hash in the database, let's say in a CHAR(100), then are you saying your primary key would be 420 bytes wide? Would you use a variable-length type like VARCHAR for email to save on some of the storage? What would happen if the email did change to something wider than before?

All of that would seem impractical when compared to a 4-byte INT, or in the case of Amazon likely an 8-byte BIGINT would be required, regardless of how it might fly in the face of the theory that a machine's idea of a physical insert attempt is an invalid key to identify a person. Or do you use a checksum or hash algorithm of some sort on the combination of email and password to reduce the size while maintaining uniqueness?

Even in the case of a bank account number you'll have a 34-byte key which could weigh down internal data processing when compared to an 8-byte BIGINT.

Bottom line question: what actual value would you store in the parent table to use in uniquely identifying a person, as well as to relate the parent person table other tables where that person's addresses (0-n) might be stored?

As an aside, a SQL Server identity column's values in a database stored on serverA are portable to serverB. In the case where serverA dies and we restore the database to serverB from backups SQL Server will know where serverA left off in terms of the next number to issue from serverB.