使用电子邮件作为 webapps 的用户名是避免“另一个在线用户名”问题的便捷方法。因此，通过使用这种方法，电子邮件应该可以在后端轻松获得以进行用户/通过检查。
但是，在 GDPR 的背景下，由于电子邮件被视为个人信息，因此应在数据库或其他存储介质上保护这些数据。
如果您对以下使用假名处理它的方法有意见，那就太好了：
大家觉得这种做法怎么样？
你认为这会产生很大的性能损失，即使是索引键列？
是否有任何其他简单的方法仍然提供将电子邮件作为用户名处理但仍符合 GDPR 的可能性？
IANAL，但 GDPR 并未强制要求对个人数据进行加密。阅读本文以更好地了解加密和 GDPR 的复杂性。
在 GDPR 中，有几篇文章明确提到加密是安全和个人数据保护措施之一。尽管根据 GDPR 加密不是强制性的，但了解建议加密的位置和原因当然很重要。
...
GDPR 加密：你应该知道的部分 在这样做之前，让我们明确一点：正如我们之前所写的，GDPR 合规性是一项业务战略挑战，严格来说加密个人数据不是强制性的。
您最好进行隐私影响评估。然后决定如何处理个人数据。如果您认为加密电子邮件用户名是一个不错的决定，那就去做吧。例如，如果您的网络应用程序名为peoplewhoarechristians.com，则用户名将被归类为敏感数据，因为它在用户与其宗教之间建立了关系。但是，个人数据的敏感程度将取决于具体情况，减轻风险的措施也将取决于具体情况。法律还谈到“实施适当的技术和组织措施，以确保适当的安全水平与风险相适应”，具体情况因情况而异。
你的方法对敏感的个人数据感觉很好。我认为这对于低风险的个人数据来说太过分了。我仍然会记录你的决定。默认情况下，电子邮件地址目前不是敏感数据。阅读这篇文章，了解敏感和非敏感之间的区别。
我们可以争辩说，提供电子邮件地址作为用户名意味着用户同意处理并意识到它可能与您的应用程序名称一起泄漏。但比抱歉更安全，因此我会要求明确同意使用。在此示例中，个人数据收集和处理的目的是身份验证和可能的访问控制，但不要忘记分析和错误记录之类的东西。如果您还打算将电子邮件用于营销目的，请务必征得额外同意。
GDPR 立法中经常使用的一个术语是，您必须“根据风险采取适当的技术和组织措施……”。这种情况下的风险是指对“数据主体”（人）造成的风险。
因此，从游戏平台到药房，合适的做法会有很大差异（因为将销售与可识别的人联系起来可能会揭示有关晚期医疗状况的信息）。
GDPR 没有设置任何技术要求，而是由您决定什么是合适的。
我会推荐一种不同的方法。其中，GDPR 要求将某些敏感信息存储在与操作数据不同的服务器中。这样，如果没有适当的权限，JOIN 将很困难或不可能。在卫生和金融系统中尤其如此。
在您的情况下，您的问题是电子邮件被视为个人数据。在不讨论你是否矫枉过正的情况下，我可以建议你一种假名化方法，它可以帮助你轻松地完成上述步骤，而不是重新设计和迁移整个数据库。
您可能希望为每个用户关联一个与电子邮件地址或用户名无关的主要标识符，例如数据库自动增量键或 GUID。然后，可以使用该键引用与该用户相关的所有内容。
现在，您可以轻松地将登录凭据存储在单独的表中。将来，如果业务需要，可以将此类表移动到不同的数据库中。
CREATE TABLE users(
userid VARCHAR(64) PRIMARY KEY, --uuid generated
language VARCHAR(2) NULL,
theme VARCHAR(30) NULL,
....
...... -- any information that is not strictly protected by GDPR
);
CREATE TABLE accounts(
userid VARCHAR(64) NOT NULL PRIMARY KEY,
email VARCHAR(256) NULL,
password_hash VARCHAR(64) NULL,
failed_logins INT NOT NULL DEFAULT 0,
last_login DATETIME NULL,
-----
);
当用户要求删除个人信息或数据保留时钟滴答作响时，不可知的 ID 可帮助您将非个人信息保存在其他表格中（例如，历史旅行列表现在变得匿名）。
您可以将上述方法提升到一个新的水平。
考虑帐户表。如果您希望允许用户删除他们自己的帐户但保留电子邮件地址的唯一性记录（例如，以防止人们重置他们的历史记录），您可以取消电子邮件地址但保留一个带有电子邮件地址哈希的附加列，因此当电子邮件地址无效时，哈希不会。
之后，当用户尝试使用较旧的电子邮件地址注册时，您有证据表明该用户已删除他的帐户：您可以决定要做什么。