SQL Server：好友类“facebook like”
我需要 1 个用户可以成为其他用户的朋友。 所以我认为我可以使用2个表：
- table
User(Id, Name, Date, Etc.) - table
Friends(UserId , Friend_UserId)
通过这些表，我可以匹配 1 个用户是其他用户的朋友。 问题是对于 1000 个用户，有 1000*1000 = 1.000000 或行。
我不知道 SQL Server 中可以存储多少行，但我的问题是 100万用户发生了什么？ SQL Server 崩溃了？
任何人都可以分享关于Friends-Class的经验（在OOP概念中我记得这是这个名字）！
I need that 1 User can be friend of other user.
So I think that I can use 2 table:
- table
User(Id, Name, Date, Etc.) - table
Friends(UserId, Friend_UserId)
With these tables, I can match that 1 user is friend of other user.
The problem is that for 1000 user, there are 1000*1000 = 1.000000 or rows.
I don't know how much row can be stored in SQL Server, but my question is
what happened for 1 milion of users? SQL Server go in crash?
Anyone can share experience about Friends-Class (in the OOP concept I remember that this was the name)!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在你的例子中 1000*1000 意味着每个用户都是每个人的朋友。为什么要存储关联？
事情真的会如此吗？或者你只是测试理论极限？
您打算存储每个关联的两份副本吗？假设用户 1 和用户 2 是朋友。您是否打算拥有一个包含这两行的表：
这将使所需的数据量增加一倍。您应该制定一条规则，两个 ID 中较小的一个始终位于一列中。
当然，请确保为这两列建立索引。
in your example 1000*1000 means every user is friends with everyone. Why store the associations at all?
Is that really going to be the case? Or are you just testing the theoretical limit?
And are you going to store two copies of every association? Say user 1 and User 2 are friends. Are you going to have a table with both of these rows:
That would double the amount of data needed. You should make it a rule that the lower of two ID's is always in one column.
And of course, make sure you index both columns.
你可以在服务器上存储 1000 个用户和朋友，你可以在服务器上存储 10000 个用户和朋友，你可以在服务器上存储 100 万个用户和朋友，但你肯定无法存储 100M 个用户和朋友，对于写入/读取数据库的响应有适当的延迟。对于社交网络规模的应用程序来说，根本没有单一的盒子可以处理成功的应用程序。这就是为什么游戏的名称是横向扩展和分片。您可以选择变得真实并暂时忽略该问题。或者您可以选择设计一个它。另请参阅使用 SQL Azure 进行分片，值得一读其他替代方案。
You can store 1000 users and friend on a server, you can store 10000 users and friends on a server, you can store maybe 1M users and friends on a server, but for sure you won't be able to store 100M users and friends and have any decent latency for responses that write/read the DB. With social web-scale apps there is simply no single box that can handle a successful app. This is why the name of the game is scale-out and sharding. You can choose to and get real and ignore the problem for now. Or you can choose to design a for it. Also, see Sharding With SQL Azure and is worth reading into other alternatives.
良好的 SQL 服务器背后的众多原因之一是专门保存和查询许多行。没有任何问题（可能超出物理服务器资源，例如 HDD 空间）会阻止表中出现 1,000,000 行。
One of the many reasons behind a good SQL server is specifically holding, and querying, many rows. There is no problem (beyond maybe physical server resources, such as HDD space) that will prevent 1,000,000 rows in a table.
是的，如果您在手机上运行它。
在适当的硬件上运行它，它可以轻松处理表中数千亿行。数据仓库项目一直都是这样做的。
Yes, if you run it on your mobile phone.
Run it on apprpriate hardare nad it can eashily handle hundreds iof billions of rows in a table. Data warehouse projects do that all the time.