我在生产中有一个数据库，有两种类型的用户。与Uber类似，我们有一个骑手＆＃39;和一个＆＃39;司机＆＃39;用户。
在我的数据库中，我有Users，Rider和Driver表。 User表包含两种用户类型之间的共享数据，Driver和Rider表包含剩余数据。
最初设计数据库时，并不认为驱动程序可能也想成为Rider。这个用例现在如何出现，我不确定如何处理数据库表。
目前，email_address字段具有唯一约束。用户还有一个user_type字段，可以是Rider或Driver。
我目前的想法是删除email_address上的唯一约束，并在email_address和user_type上创建一个唯一索引，允许用户使用应用程序的两面。
这确实会产生需要指定正在使用哪种类型用户的问题，例如，在调用/ login时。我想我现在需要做一些像/ login？type = rider。
有没有更好的方法呢？我们正在制作中，所以我不能废弃并重新创建，但如果有更好的解决方案，我愿意迁移数据。
答案 0 :(得分：0)
我的建议有点太大而无法发表评论，所以请听我说。 确切的解决方案很难，因为我还没有看到你在应用程序中如何使用这些表。所以这个解决方案是根据一些假设设计的。
在登录时，您需要确定用户是否要以驱动程序或骑手身份登录。通常，驱动程序的链接应该与用户链接不同。或者应该有一面旗帜。
对于车手，您不需要额外的验证。但并不是每个人都应该被允许以驱动程序身份登录（例如，如果用户错误地尝试登录为驱动程序，系统不应该允许这样做。）
这意味着您的初始用户表和驱动程序表不需要任何修改。现在，如果您不是驱动程序，则用户角色应默认为rider。 如果您是骑手登录的骑手，则无需进行任何更改。 我假设你的代码库中有一个角色设置机制。
但是，如果您是以驱动程序身份登录的驱动程序，则现有逻辑应继续使用此附加标志，即您应检查代码中是否存在标志，然后才允许检查表中的驱动程序。如果你是一名作为骑手进入的车手，那么国旗必须是没有。
现在您有2个选项。首先是让驱动程序仅作为驱动程序表中的rider数据进入，其次是在rider表中创建一个条目并使用它。这两种方法都可行（您必须根据标志调整应用程序逻辑以获取正确的表）。我的建议是去骑手表，这应该减少系统的进一步复杂性。所以基本上，一个用户，如果他有时是司机和骑手，应该在驱动程序和骑手表中都有条目（假设你的约束只在用户表上），你应该根据人在记录的角色使用正确的条目希望，一旦使用正确的表登录，系统的更改将是最小的。