社交对象 - 数据库结构的最佳实践，筛选，整理，可扩展性 [英] Social Objects - best practices for database structure, filtering, sorting, extensibility
问题描述
我们正处在ASP.NET MVC构建一个通用的企业社交网络平台的过程。其中的任何社交网站的主要功能是由用户明确地（文字更新，照片，博客，视频等）或隐式（用户参加事件贴在社交对象用户已经更新的页面等）。
We're in the process of building a generic enterprise social networking platform in ASP.NET MVC. One of the key features of any social networking website are the social objects that are posted by users either explicitly (text updates, photos, blogs, videos etc) or implicitly ('user is attending event', 'user has updated page' etc).
这些都是本质上非常相似 - 也就是说，它们都显示在用户的活动流，在它们发布到群组页面，在用户的用户配置文件谁张贴他们和以类似的方式过滤 - 例如， 告诉我，在过去的 7天发生在组X 与代码是一切。
These are all essentially fairly similar - i.e. they are all displayed on users' activity streams, on the group pages that they are posted to, on the user profiles of users who posted them and filtered in similar ways - e.g. "show me everything that happened in the last 7 days for group X with the tag Y".
我们要定义几个核心岗位类型（博客，文字更新，活动参与，网页编辑等），但有能够轻松地扩展，使软件的代理商和客户可以添加自己的类型（的能力如新闻报道）用自己的自定义元数据和领域（这应该是搜索/过滤）。 ！这些看成是SharePoint列表的社会等同
We want to define a few core post types (blog, text update, event attendance, page edited etc) but to have the ability to easily extend so that resellers and clients of the software can add their own types (e.g. news-article) with their own custom metadata and fields (which should be searchable/filterable). Think of these as the "social" equivalent of Sharepoint lists!
反正我的问题是：什么是最好的数据结构在性能，可扩展性方面达到这个？和易于扩展的
Anyway the question I have is: What is the best data structure to achieve this in terms of performance, scalability and ease of extensibility?
这是我目前思考（伪代码/数据库结构）：
This is what I'm currently thinking (pseudo code / database structure):
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;
}
（所有数组引用在数据库中不同的表）
(All arrays reference separate tables in the DB)
这是一个明智的办法做到这一点？ - 即存储在同一个表中的所有社会对象（允许通过元数据表的附加字段/信息延伸）还是我的东西抽烟我不应该？请记住，这个表很可能会变得非常大 - 100,000s到数百万行。
Is this a sensible way to do it? - i.e. store all social objects in the same table (and allow extending via the metadata table for additional fields/info) or am I smoking something I shouldn't be? Bear in mind that this table is likely to become quite large - 100,000s to millions of rows.
欢呼声中，
马库斯
cheers, Marcus
推荐答案
的这篇文章通过Facebook的工程师应该给你的主要问题是什么，当谈到缩放的想法。大部分情况你需要考虑如何能迅速生成/服务由给定用户的朋友的所有帖子的列表。
This post by a Facebook engineer should give you an idea of what the major issues are when it comes to scaling. Mostly you need to consider how quickly can you generate/serve a list of all posts made by a given user's friends.
这篇关于社交对象 - 数据库结构的最佳实践，筛选，整理，可扩展性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
