这是我在某处发现的一个有趣的面试问题。详细说明:
你应该为一些网站设计类和数据结构，比如facebook或linkedin，在那里你的活动可以共享和再共享。设计应该避免冗余和重复。
在思考这个问题时，我被卡在"链接vs复制"问题上，正如这里讨论的
但是由于问题指出应该避免重复，我决定采用"链接"方式。这使得分享/再分享更容易，但删除非常困难。例如，如果原始用户删除了他们的帖子，那么所有的共享都应该被删除。(从编程上讲，指向特定活动的所有对象都应该为空。这是比较困难的部分，也就是找到所有指向的对象)
保留这些股份不是更好吗?原用户删除他们的帖子，好吧，没了。但所有与它有关联的人都应该这么做而不是让它突然消失。
这可以用Unix处理硬链接的方式来完成。"删除"意味着删除一个指向一个对象的链接——在Unix术语中是一个索引节点。你在链接数为零之前，不要删除对象本身。
从原始规范来看，删除应该像您描述的那样工作并不明显。可能希望当原始用户删除项时，它不会在其他地方被删除;在这种情况下，您不一定需要跟踪所有引用，只需保持每篇文章的引用计数，并仅在计数为零时将其从数据库中删除。
如果你确实想要你描述的行为，它可以通过简单地删除坏链接来实现，当你遇到它们的时候，再次减轻你跟踪每个引用的需要。跟踪和更新每个帖子的每个引用的成本被替换为每个引用页面查找失败的可比成本。不过，后一种情况实现起来更简单，而且成本不会一下子全部影响到服务器。
在现实生活中，我会将所有引用都实现为双向的，因为在添加功能时迟早可能需要它。例如，"喜欢"计数器看起来很简单，但为了防止重复投票，你需要跟踪谁喜欢每个项目，然后如果你想在他们删除个人资料时删除他们的"喜欢"，你也需要保留每个用户的出站"喜欢"列表。
实现Facebook之类的东西需要大量的数据库活动