我应该为社交网络数据库的用户及其个人资料创建单独的表吗?

发布于 2024-10-18 08:47:02 字数 69 浏览 2 评论 0原文

我想为社交网络设计一个数据库,为用户提供个人资料。我应该为用户及其个人资料使用单独的表,还是只为用户及其所有属性使用一张表?

I want to design a database for a social network which will provide profiles for users. Should I use separate tables for users and their profiles or just one table for users and all attributes in it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

归途 2024-10-25 08:47:02

如果你想做大,那就为用户单独做一个。

用户和属性同表的优点:

  • SQL查询更简单。
  • 如果您假设您始终需要这些属性,那么就会少一个连接。

单独表的优点:

  • 在现实生活中,您并不总是需要属性。
  • 当您需要将其他事物与用户配对时,您不需要所有属性。

If you want to go big, then do a separate one for the users.

Advantage of users and attributes in same table:

  • Simpler SQL query.
  • If you assumer that you will always need the attributes, then there's one less join.

Advantage of separate tables:

  • In real life, you don't always need the attributes.
  • When you need to pair other things with users you don't need all the attributes.
零崎曲识 2024-10-25 08:47:02

如果您打算使用关系数据库,我会推荐一个单独的表(规范化、外键等)。

如果您有兴趣尝试其中一种文档存储数据库(例如 MongoDB、CouchDB、RavenDB),那么我会首先考虑访问用户时是否正常访问属性。如果是这样,那么您应该将属性作为嵌入文档放置在用户内部。

祝你好运!

If you're going to use a relational database, I would recommend a separate table (normalized, foreign-keys, etc.)

If you are interested in trying one of the document-store databases (e.g., MongoDB, CouchDB, RavenDB), then I would consider first if you normally access attributes when you access a user. If so, then you should place the attributes inside the user as embedded documents.

Good luck!

梦忆晨望 2024-10-25 08:47:02

将它们分开,用户和配置文件松散耦合从长远来看会很有帮助。个人资料可以是社区、群组的,而不仅仅是用户的,所以我建议将它们分开。

Keep them separate, Users and Profiles loosely coupled would be helpful in the long run. Profiles can be of communities, groups too not just users, so I suggest keeping them separate.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文