在linkedin，当您访问某人的个人资料时，您可以看到您与他们的联系方式。我相信linkedin显示了高达3级的连接，如果不是更多的话，比如
shabda -> Foo 用户、bar 用户、baz 用户 -> Joel 的连接 -> Joel
我怎样才能在数据库中表示这个。
如果我建模为，
用户 身份PK 姓名字符 联系 用户 1 FK 用户 2 FK
然后要找到网络，三层深，我需要获取我所有的连接，他们的连接，以及他们的连接，然后查看当前用户是否在那里。这显然对于任何大小的数据库都是非常低效的，并且可能也很笨重。
因为，在链接时我可以看到这个网络，在我访问的任何个人资料上，我认为这也不是预先计算的。
我想到的另一件事可能是最好不要将其存储在关系数据库中，但是存储和检索它的最佳方法是什么？
我的建议是使用图形数据库。目前似乎只有一种实现可用，那就是Neo4j。它是用 Java 编写的，但绑定到 Ruby 和 Scala（Python 正在进行中）。
如果您不了解 Java，那么不幸的是，您可能无法在任何其他平台上（目前）找到类似的东西。但是，如果您确实了解 Java（或至少愿意学习），那么这是值得的。（从技术上讲，由于 Ruby/Python 绑定，您甚至不需要学习 Java。） Neo4j 正是为您想要做的事情而构建的。尝试在关系数据库中实现这一点会遇到很多麻烦，因为您只需几行 Java 代码就可以完成完全相同的事情，而且效率更高。
如果这不是一个选项，我仍然建议查看其他数据库类型，例如object databases。关系数据库不是为这种事情而构建的，尝试在 RDBMS 中进行操作会比切换到不同类型的数据库并学习它更痛苦。
我不明白为什么为此使用关系数据库有什么问题。问题中定义的表格是一个很好的开始。通过适当的优化，您将能够保持良好的性能。我个人认为你需要一些严肃的东西来证明从这种多功能的主流产品转移是合理的。无论如何，您可能需要在项目中使用 RBDMS，并且在许多价格范围内（甚至免费）都有大量的合法选择。您将获得高质量的文档，将获得支持，并且您将在工作池中拥有大量训练有素的开发人员。
关于这种自我关系模型（用户加入其他用户），我建议研究递归查询。这将使您无法执行级联的单个查询来查找 3 个级别的关系。考虑使用 CTE 执行递归查询的以下 SQL Server 方法。
http://msdn.microsoft.com/en-us/library/ms186243.aspx
它允许您指定要使用 MAXRECURSION 提示的深度。
接下来，您需要开始思考优化的方法。这从使用适当的索引和维护等设置表的标准最佳实践开始。它不可避免地以denormalization结束。这是您只有在尝试过其他所有方法后才要做的事情之一，但是如果您知道自己在做什么并使用良好的做法，那么您的性能提升将是显着的。互联网上有很多资源可以帮助您了解非规范化，只需查找即可。