社交对象 - 数据库结构、过滤、排序、可扩展性的最佳实践答案

【问题标题】：Social Objects - best practices for database structure, filtering, sorting, extensibility社交对象 - 数据库结构、过滤、排序、可扩展性的最佳实践
【发布时间】：2011-03-24 08:05:59
【问题描述】：

我们正在用 ASP.NET MVC 构建一个通用的企业社交网络平台。任何社交网站的主要功能之一是用户明确（文本更新、照片、博客、视频等）或隐式（“用户正在参加活动”、“用户已更新页面'等）。

这些本质上都非常相似 - 即它们都显示在用户的活动流上、他们发布到的组页面上、发布它们的用户的用户个人资料上并以类似方式过滤 - 例如。 “用标签 Y 向我展示过去 7 天 X 组 发生的一切”。

我们希望定义一些核心帖子类型（博客、文本更新、活动出席、页面编辑等），但要能够轻松扩展，以便软件的经销商和客户可以添加自己的类型（例如新闻-文章）具有自己的自定义元数据和字段（应该是可搜索/可过滤的）。将这些视为 Sharepoint 列表的“社交”等价物！

无论如何，我的问题是：在性能、可扩展性和易扩展性方面实现这一目标的最佳数据结构是什么？

这就是我目前的想法（伪代码/数据库结构）：

public class SocialObject
{
 int Id;
 DateTime Date;
 string Url;
 string Title;
 string Text;

 Media[] Attachments; //photos, videos, links etc

 int OwnerId; //user who posted it
 int GroupId; //group it was posted to
 int PageId; //page it was posted to
 int PostTypeId;
 int? SourceId; //source - e.g. desktop client, email, web

 Like[] Likes;
 Comment[] Comments;
 Repost[] Reposts;

 Tag[] Tags;
 Mention[] Mentions; //user IDs mentioned in this post
 Metadata[] MetadataValues;
}

public class Metadata
{
 int SocialObjectId;
 int MetadataTypeId;
 int? MetadataValueId; //for metadata types with list values - for filtering
 string Value;
}

（所有数组都引用数据库中的单独表）

这是一种明智的做法吗？ - 即将所有社交对象存储在同一个表中（并允许通过元数据表扩展其他字段/信息）或者我是否在抽我不应该抽的东西？请记住，此表可能会变得非常大 - 100,000 到数百万行。

干杯，马库斯

【问题讨论】：

标签： c# database filtering social-networking

【解决方案1】：

Facebook 工程师的This post 应该让您了解在扩展方面存在哪些主要问题。大多数情况下，您需要考虑生成/提供给定用户的朋友发布的所有帖子的列表的速度。

【讨论】：

【解决方案2】：

还发现了来自 MySpace 的有关同一问题的视频演示： http://ecn.channel9.msdn.com/o9/mix/10/mp4/EX04.mp4

【讨论】：