创建用户注册系统时,我将使用用户的电子邮件作为用户名。
创建数据库模式时,我应该将它们视为 2 个单独的字段还是应该将它们视为 1?
例如。
USER_TABLE {USER_ID, USERNAME, FNAME, LNAME, EMAIL}
或者
USER_TABLE {USER_ID, USERNAME, FNAME, LNAME}
如果我们决定让用户创建一个不是电子邮件的用户名,我认为单独存储 2 个字段(即使它们相同)的唯一参数是为了某种未来的证明?
想法?
创建用户注册系统时,我将使用用户的电子邮件作为用户名。
创建数据库模式时,我应该将它们视为 2 个单独的字段还是应该将它们视为 1?
例如。
USER_TABLE {USER_ID, USERNAME, FNAME, LNAME, EMAIL}
或者
USER_TABLE {USER_ID, USERNAME, FNAME, LNAME}
如果我们决定让用户创建一个不是电子邮件的用户名,我认为单独存储 2 个字段(即使它们相同)的唯一参数是为了某种未来的证明?
想法?
我会避免过早的优化,只使用一个字段。如果您需要有 2 个字段,则可以轻松创建和填充一个。
您可以包含这两个属性,但添加一个约束(“检查”约束)以保证用户名和电子邮件相同。然后可以针对适当的属性编写需要用户名或电子邮件的业务逻辑,并且当您需要使它们独立时,您可以删除约束。
不要忘记用户名和/或电子邮件的唯一性约束。
如果您认为您可能希望允许用户开始创建不是电子邮件地址的用户名,那么保留单独的 email 和 user_id 列是一个好主意。如果您正在构建一个新系统,则尤其如此。
我在系统设计中有一句格言:“如果有人想到了这个想法,它最终会发生。”
我的意思是,认为“我们的业务规则在 X 领域永远不会改变”通常是错误的。业务规则变化很多。
您以后可以随时向表中添加一个新字段,以区分电子邮件和 user_id。添加一列很容易。更难的是更改您编写的所有将原始 user_id 列用于电子邮件目的的代码。这就是为什么我说从一开始就在代码中建立 user_id 和 email 之间的区别是个好主意。