我需要设计/架构/开发基于网络的社交网络类型的应用程序。
基本功能：
- 用户在系统上创建帐户
- 用户同意互相“加为好友”
- 用户在系统内创建内容
- 用户指定哪些朋友可以查看/编辑他们创建的内容
这个核心功能肯定已经创建过很多次了吗？有没有关于如何实现这类事情的最佳实践模式？
我最感兴趣的是这个数据库的外观。
从 SQL 的角度来看（任何数据库），这会是什么样子？
从 NOSQL 的角度来看（任何 NOSQL 数据库）会是什么样子？
我最感兴趣的是，如何在数据库中解决“内容可见性”的问题？即数据库/应用程序如何确保只有经过批准的朋友才能看到用户创建的内容？
谢谢
First thing to get out the way is the database, an SQL one would just look like a normalised sql database. What else could it look like? A nosql database would look like a bunch of name value pair files.
Three approaches to building a social web site after and only after you do a shed load of research on existing popular and unpopular ones to ascertain their architecture and the markets that that they are aimed at, and the particular services that they offer to these markets.
How is "content visibility" handled. Initially of course the site builder makes a decision on who can see content. Owners only, friends, registered users, the general public? etc. But this decision must fir in with the aims and policies of the site. The best way then to handle this is through Role Based Access RBAC see here for details
When you say you "need to design / architect / develop" is this because of an overwhelming inner urge or because someone is paying you?
Either way remember the social web space is very very crowded. If you are just building another YouTube, or FaceBook then you are unlikely to be able to generate the critical mass of number required to make such a site commercially successful.
If it is for a niche market not already catered for, e.g. "The Peckham and Brockley Exotic Bird Fanciers Club" then you know what you market is and what features will be required so any of the above options you deem the easiest and cheapest can be used but that is up to you to analyse and execute.
You may of course have an idea for a social site that is mainstream and is not covered by the other, i.e. you have spotted the mythological "gap in the market". In this case go for it but prepare to be disappointed. Or not.
Your design should be maintenable. This is what I have in my project.
1.) Application.Infrastructure
2.) Application.DataModel
3.) Application.DataAccess
4.) Application.DomainObjects
5.) Application.BusinessLayer
6.) Application.WebClient or Application.WindowsClient
Application.BusinessObjects are used across the application and they travel across all layers whenever neeeded [except Application.DataModel and Application.Infrastructure]
All my queries are defined only Application.DataModel.
Application.DataAccess returns or takes Business objects as part of any data-access operation. Business objects are created with the help of reflection attributes. Each business object is marked with an attribute mapping to target table in database and properties within the business object are marked with attributes mapping to target coloumn in respective data-base table.
My validation framework lets me validate each field with the help of designated ValidationAttribute.
My framrwork heavily uses Attributes to automate most of the tedious tasks like mapping and validation. I can also new feature as new aspect in the framework.
A sample business object would look like this in my application.
User.cs
[TableMapping("Users")]
public class User : EntityBase
{
#region Constructor(s)
public AppUser()
{
BookCollection = new BookCollection();
}
#endregion
#region Properties
#region Default Properties - Direct Field Mapping using DataFieldMappingAttribute
private System.Int32 _UserId;
private System.String _FirstName;
private System.String _LastName;
private System.String _UserName;
private System.Boolean _IsActive;
[DataFieldMapping("UserID")]
[DataObjectFieldAttribute(true, true, false)]
[NotNullOrEmpty(Message = "UserID From Users Table Is Required.")]
public override int Id
{
get
{
return _UserId;
}
set
{
_UserId = value;
}
}
[DataFieldMapping("UserName")]
[Searchable]
[NotNullOrEmpty(Message = "Username Is Required.")]
public string UserName
{
get
{
return _UserName;
}
set
{
_UserName = value;
}
}
[DataFieldMapping("FirstName")]
[Searchable]
public string FirstName
{
get
{
return _FirstName;
}
set
{
_FirstName = value;
}
}
[DataFieldMapping("LastName")]
[Searchable]
public string LastName
{
get
{
return _LastName;
}
set
{
_LastName = value;
}
}
[DataFieldMapping("IsActive")]
public bool IsActive
{
get
{
return _IsActive;
}
set
{
_IsActive = value;
}
}
#region One-To-Many Mappings
public BookCollection Books { get; set; }
#endregion
#region Derived Properties
public string FullName { get { return this.FirstName + " " + this.LastName; } }
#endregion
#endregion
public override bool Validate()
{
bool baseValid = base.Validate();
bool localValid = Books.Validate();
return baseValid && localValid;
}
}
BookCollection.cs
/// <summary>
/// The BookCollection class is designed to work with lists of instances of Book.
/// </summary>
public class BookCollection : EntityCollectionBase<Book>
{
/// <summary>
/// Initializes a new instance of the BookCollection class.
/// </summary>
public BookCollection()
{
}
/// <summary>
/// Initializes a new instance of the BookCollection class.
/// </summary>
public BookCollection (IList<Book> initialList)
: base(initialList)
{
}
}
像http://www.neo4j.org这样的图形数据库是一个值得一看的选择。它非常适合社交网络（例如http://blog.neo4j.org/2009/09/social-networks-in-database-using-graph.html）和基于 ACL 的安全性（例如http: //wiki.neo4j.org/content/ACL）。
正如 Aaroon 所指出的，您应该首先问自己要解决什么问题。
您希望人们分享什么内容？它真的应该只对朋友可见吗？如果您让内容公开可见，它会更容易和可扩展，因为显示的内容不取决于谁在观看页面，您可以轻松地缓存它。公开可用的用户生成内容吸引了新用户。
如果您想限制访问并让用户有机会将朋友组附加到资源，我会使用简单的基于组的访问控制。让每个资源有一组可以编辑资源的用户和一组可以看到它的用户。
这样，每个资源都有两个单值属性，并且每个用户都属于有限数量的组。您可以将 view-group 和 edit-group 属性附加到存储在 NOSQL 数据库、搜索引擎（如 Lucene/Sphinx）或 SQL 数据库中的行中的文档。查询用户可用的内容时，传递用户所属的所有组（在 SQL 中，您将使用IN子句，在 SphinxsetFilter('view-group', array(2,3,4))中。数据库将仅返回用户可用的内容。因为您仅附加 2 个整数值（视图组和编辑组）添加到文档中，您可以将它们存储在内存中，从而使搜索快速且可扩展。
您应该首先研究现有的社交网络（Facebook、Myspace 等）。有大量关于它们如何实施的信息。
最后，看起来 Elgg 或 Dolphin 可能会满足我们的要求。这些似乎是用于滚动您自己的社交网络的 PHP 框架。我查看了 Facebook 平台，但没有任何地方清楚地解释它是什么——它似乎是 facebook 代码，但也许它只是插件 API 或其他东西的代码。
社交网络成功的关键不是它所基于的技术，而是它们为用户解决的问题。如果用户喜欢它，即使你的技术很垃圾，你也注定要成功。
[编辑] 它是如何实现的？检查任何基于 SQL 的用户角色系统。在这种情况下，每个用户也是一个角色，可以将其添加为“允许访问”任何对象。根据您拥有的对象数量以及控件的细粒度，这可能意味着您有一个包含三列的表：OBJECT, USER, ACCESS_TYPE其中ACCESS_TYPE可以是OWNER、READ（朋友）、WRITE（亲密朋友）之一。
该表将变得非常大，但几亿行对于当今的数据库来说并不少见。