我对正确构建我的应用程序并为其提供良好且一致的 API 有一些想法，但现在我对用户/帐户模型有一些疑问。
这很有趣，但如果您考虑某些应用程序，您会发现它们将您视为用户，但在编辑您的详细信息时，您会重定向到帐户。
推特就是一个很好的例子。
所以我想知道您对构建这种架构的最佳方法有何看法？
账户真的有必要吗？
为什么我应该使用帐户或用户？
如果我决定稍后为该用户实施付款指令，该用户是否应该将该信息存储在存储其密码和其他重要信息的帐户中？
抱歉，但我在这个主题上有点迷失，有时看起来其他应用程序使用的模型比必要的要多，所以我不确定:(
我想我必须像这样关联模型：
User has_one :account
但我仍然不确定什么样的信息会进入用户和帐户。
提前感谢您的帮助
干杯。
I'm having some thoughts about proper building my app and provide a good and consistent API for it but now I'm having some doubts about the user/accounts model.
It's funny but if you consider some apps you will see that they treat you like user but when editing your details your are redirect to account.
One good example of this is twitter.
So I would like to know your opinion about what's the best method to build this kind of architecture?
Is the account really necessary?
Why should I use account or user?
If I decide to implement a payment instruction for that user later, should that user store that information inside a account which stores his password and other important information?
sorry but I'm kind of lost on this subject sometimes it looks that other apps use more models than the necessary, so I'm not sure :(
I was thinking I'm have to associated models like this:
User has_one :account
But I still not sure what kind of information goes into the User and Account.
Thanks in advance for you help
Cheers
发布评论
评论（1）
这实际上取决于应用程序。以电话为例。一个家庭或公司可能有一部或多部电话一起计费，因此电话号码与帐号不同。
对于许多 Web 应用程序来说，一个用户一个帐户，反之亦然。我可以开设多个帐户，一个是“马克电脑家伙”，一个是“马克钢琴家”等等。所以用户不是一个真实的人，而更像是一个角色，或者是我扮演的角色。如果我的音乐事业真正起飞，我可能会聘请一名公关人员来管理我的“马克钢琴家”帐户。在这种情况下，应用程序可以将“用户”和“帐户”联系在一起：每个“角色”一个帐户。这对于免费应用程序来说是很好的。
举一个不同的例子，看看需要花钱的网络托管服务。我可能会创建一个帐户，然后设置多个可以登录的用户：我、我的 Web 开发人员、我的系统管理员等。因此，一个帐户可用于多个用户。
It really depends on the application. Look at telephones for example. One household or company may have one or more telephones billed together, so telephone number is not the same as account number.
For many web applications, there is one account for one user and vice versa. I can open several accounts, one as "Mark the computer guy", one as "Mark the pianist" and so on. So a user is not a real person but more like a persona, or a character I play. If my music career really takes off I might hire a P.R. person to manage my "Mark the pianist" account. In this case the application could tie "user" and "account" together: one account for each "persona". This is good for a free app.
For a different example, look at a web hosting service that costs money. I might create one account and then set up several users who can log on: me, my web developer, my systems administrator, etc. So there's one account for several users.