电商APP仅手机号注册场景下，第二种数据库设计方案是否可行？

1. 数据一致性风险高 #

你的业务核心是必须完成手机号验证才能创建用户，但第二种方案里users表只有id和name，意味着你可能得先创建一个无身份凭证的“空用户”，再去关联verify_phone表做验证——这反而会产生大量未验证的无效用户数据，直接违背了合作伙伴“避免未完成OTP验证时产生重复数据”的要求。

另外，verify_phone和users是严格的一对一关系，但单独成表后，如果没给user_id加唯一索引，很容易出现一个用户对应多条手机号记录的情况；加了约束又会增加数据库维护复杂度，完全没必要。

2. 报表与查询效率低下 #

电商场景常需要统计用户维度的数据（比如已验证用户数、手机号分布等），第二种方案需要多次关联users、verify_phone、user_resources甚至verify_email表，不仅SQL语句冗长，查询性能也会随数据量增大而下降。相比之下，核心身份信息集中在一张表的方案，报表生成和日常查询都简单得多。

3. 业务逻辑冗余 #

既然你的APP仅支持手机号登录/注册，手机号是用户的核心身份凭证，完全没必要拆到单独的verify_phone表。这种过度拆分只会让业务逻辑零散：比如登录时要先查verify_phone找手机号，再关联users找用户信息，多此一举。

优化你的第一种方案 #

你的初始方案思路更合理，可以再做一点完善贴合业务需求：

users:
    id (主键)
    name
    phone (唯一索引，避免重复手机号)
    email (可选)
    phone_verified (布尔值，标记是否完成OTP验证)
    created_at

user_resources:
    id (主键)
    user_id (外键关联users.id)
    otp (验证码)
    otp_expire_time (过期时间，避免无效验证码)
    created_at

这样做的好处：

• 只有用户完成OTP验证后，才将users.phone_verified设为true，确保只有验证通过的用户才算有效用户
• phone加唯一索引，从数据库层面避免重复手机号注册
• 所有核心用户信息集中在users表，查询和报表生成更高效

内容的提问来源于stack exchange，提问作者Bhaskar