如何避免为只能具有 3 个可能值并且是多对多关系的一部分的对象定义两个额外的表？
How to avoid defining two extra tables for an object that can have only 3 possible values and is part of a many-to-many relationship?
我试图在网上搜索这个问题，但发现这个问题很难以简洁易懂的方式表述。
我正在开发一个应用程序，它允许用户从 3 种身份验证类型中进行选择：密码、指纹和面部识别。每个用户都可以选择这 3 种中的多种类型，我需要将他们的选择存储在关系数据库中。所以理论上，用户和authentication_types.
之间存在多对多的关系
我知道这看起来很微不足道，可能我分析过度了，但是哪种方法是在关系数据库级别对其进行建模的最佳方式？我试图避免但似乎是关系数据库设置中唯一合理的解决方案是为登录类型（比如 LoginTypes）创建一个 table 来存储上面提到的 3 种登录类型并创建一个中介table 用于多对多关系（例如 UsersLoginTypes）。
让我有点沮丧的是，对于只有 3 种类型的登录，我需要创建一种 table 来存储它们，另一种用于多对多关系。任何时候我想获得用户选择的登录类型，我都不能简单地 select 用户并从用户的对象中提取登录类型，但我需要进行一个涉及另外两个 tables（登录类型和用户登录类型）。我在这里错过了一个更简单的解决方案吗？
我考虑过为每个登录类型分配一个数字（例如，密码 - 1、指纹 - 2、人脸识别 - 3），并在用户模型中为登录类型设置一个字段，用于存储包含以下内容的字符串对应于用户选择的数字。最终，如果不存在更好的解决方案，这也许就是我想要的。
PS。我在 Rails 上使用 Ruby 和 ActiveRecord，如果这改变了什么。
1997年，我曾经把一个关系数据库模型规范化死了。它工作正常，非常灵活，但每当您想要制定无法预料的查询时，它总是会停顿下来。首先制定查询已经非常繁琐。 （当然，那是你总是手动编写 SQL 的时候——BI 工具是未来的东西）。
所以：a (master) table users , a (lookup) table login_types and a (child/intermediate) table active_users_authentications 因为您的第一个镜头是建立关系模型的正确方法。
但是，如果您希望系统成为 efficient/performant（并且您不需要身份验证配置的任何进一步详细信息 - 当然，您将存储在 active_users_authentications 中），我支持人们会发现在 users table 中有 3 个布尔值 (Yes/No) 列并称它们为：has_pwd_auth、has_fgnpr_auth 和 [=17 是绝对合法的=].
我试图在网上搜索这个问题，但发现这个问题很难以简洁易懂的方式表述。
我正在开发一个应用程序，它允许用户从 3 种身份验证类型中进行选择：密码、指纹和面部识别。每个用户都可以选择这 3 种中的多种类型，我需要将他们的选择存储在关系数据库中。所以理论上，用户和authentication_types.
之间存在多对多的关系我知道这看起来很微不足道，可能我分析过度了，但是哪种方法是在关系数据库级别对其进行建模的最佳方式？我试图避免但似乎是关系数据库设置中唯一合理的解决方案是为登录类型（比如 LoginTypes）创建一个 table 来存储上面提到的 3 种登录类型并创建一个中介table 用于多对多关系（例如 UsersLoginTypes）。
让我有点沮丧的是，对于只有 3 种类型的登录，我需要创建一种 table 来存储它们，另一种用于多对多关系。任何时候我想获得用户选择的登录类型，我都不能简单地 select 用户并从用户的对象中提取登录类型，但我需要进行一个涉及另外两个 tables（登录类型和用户登录类型）。我在这里错过了一个更简单的解决方案吗？
我考虑过为每个登录类型分配一个数字（例如，密码 - 1、指纹 - 2、人脸识别 - 3），并在用户模型中为登录类型设置一个字段，用于存储包含以下内容的字符串对应于用户选择的数字。最终，如果不存在更好的解决方案，这也许就是我想要的。
PS。我在 Rails 上使用 Ruby 和 ActiveRecord，如果这改变了什么。
1997年，我曾经把一个关系数据库模型规范化死了。它工作正常，非常灵活，但每当您想要制定无法预料的查询时，它总是会停顿下来。首先制定查询已经非常繁琐。 （当然，那是你总是手动编写 SQL 的时候——BI 工具是未来的东西）。
所以：a (master) table users , a (lookup) table login_types and a (child/intermediate) table active_users_authentications 因为您的第一个镜头是建立关系模型的正确方法。
但是，如果您希望系统成为 efficient/performant（并且您不需要身份验证配置的任何进一步详细信息 - 当然，您将存储在 active_users_authentications 中），我支持人们会发现在 users table 中有 3 个布尔值 (Yes/No) 列并称它们为：has_pwd_auth、has_fgnpr_auth 和 [=17 是绝对合法的=].