这可能不是一个合适的地方，但是我想出了是否想要这种基础架构类型的专家，所以这里可能会有这样的地方。
我与CTO碰壁。
基本上，我有一个使用SSO模型的后端，由于多个帐户无法共享电子邮件地址，所以我被告知“电子邮件地址基本上是用户的主要键引用。”
[我整个上午都在使用此示例来指出Microsoft的Auth结构，该结构“向用户询问”电子邮件地址，然后列出具有该地址的所有帐户供您选择，然后使用密码进行身份验证，其他遵循OAuth的提供程序标准也遵循类似的UI结构。
[CTO似乎从此推断出，电子邮件地址基本上与userId（用于在整个SSO环境中标识用户的主键）相同，因此具有单独的PK是“微软的复杂性毫无意义。只是出于某些BS原因”。
我担心的典型例子...
重用问题：有些人甚至是小型企业共享电子邮件地址。就像电话号码一样，电子邮件也可以重复使用。一年后，Jsmith @ somecompany.com可以轻松属于约翰·史密斯，两年后可以轻松属于茱莉亚·史密斯。
更新问题：电子邮件的另一个问题是它们经常更改。如果您要使用其他键加入其他表，那么您还必须更新其他表，这在整个客户公司更改其电子邮件时都会对性能造成很大的影响（我见过这种情况。）
] >多重帐户问题：我有一个Microsoft帐户，该帐户是我加入公司时将我的MSDN子链接到的。后来，公司获得了Azure订阅，并为我创建了一个链接到相同电子邮件地址的帐户。老板声称这些应被视为同一帐户，因此我的组织应拥有@ mycompany.com域，因此应进行管理。
多重解决方案问题：我有一个电子邮件地址，我注册使用该地址在CMS中使用一个应用程序。后来我注册使用了我们CMS中的另一个应用程序（所以同一个SSO，我们公司的不同客户）。是同一帐户，这些应用程序的哪些管理员可以“管理我的帐户”？
多个提供商的问题：我有一个链接到我的Facebook，google和Microsoft帐户的电子邮件地址，我想将它们链接到我的公司帐户，以便我可以使用这些凭据登录，它们都共享一个电子邮件地址，但它们也是多个远程帐户。 。如果我想将它们链接到不同的本地帐户并将远程电子邮件地址用于我们系统中的所有通信，该怎么办？
在我看来，电子邮件地址对于任何重要的事物都不会被视为主键，而对于像安全模型这样至关重要的事物则更是如此，老板不同意。
我在这里错了吗？
这可能不是一个合适的地方，但我想出了是否想要这种基础设施类型的专家，这里可能会有一些地方。我与CTO碰壁。 ...
如您的措辞，“因为多个帐户无法共享电子邮件地址。”似乎暗示电子邮件应该是Unique