Facebook 的 DB 模式，例如 Wall +“共享链接”答案

【问题标题】：DB Schema for Facebook like Wall + "Shared links"Facebook 的 DB 模式，例如 Wall +“共享链接”
【发布时间】：2011-04-13 09:49:07
【问题描述】：

我正在为 facebook 制作一个类似墙结构的数据库模式。我需要保存墙上的帖子、分享链接、分享视频到我的数据库中。直到现在我能够制作这个架构：

GO
CREATE TABLE [Wall]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [PostText] [nvarchar](MAX)
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [DateCreated] [datetime] NULL 
    )
GO

接下来我必须添加架构以添加“共享链接”和“共享视频”功能。

GO
CREATE TABLE [Wall]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [WallText] [nvarchar](MAX)
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [DateCreated] [datetime] NULL,

      [SharedLink] [nvarchar](1024)  NULL ,
      [SharedLinkTitle] [nvarchar](512)  NULL ,
      [SharedLinkDesc] [nvarchar](512)  NULL ,
      [SharedLinkImageSrc] [nvarchar](512)  NULL 
    )
GO

现在有了这个架构：

第一种情况：插入墙帖时，[SharedLink]、[SharedLinkTitle]、[SharedLinkDesc]、[SharedLinkImageSrc] 列将被插入为空，其余列将具有值。

第二种情况：插入“链接共享”时，“[WallText]”列将作为空值插入，其余列将具有值。

对于我的案例，70% 的时间将发布墙贴，30% 的“链接”将被共享，这意味着 70% 的案例 [SharedLink]、[SharedLinkTitle]、[SharedLinkDesc]、[SharedLinkImageSrc] 将是插入为空。现在我担心的是是否可以插入空列，或者我应该为“共享链接”的目的而使用单独的表，并使用这样的分隔表：

GO
CREATE TABLE [LinkShared]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [SharedLink] [nvarchar](1024)  NULL ,
      [SharedLinkTitle] [nvarchar](512)  NULL ,
      [SharedLinkDesc] [nvarchar](512)  NULL ,
      [SharedLinkImageSrc] [nvarchar](512)  NULL 
    )
GO

我必须以类似的方式添加架构以进一步共享视频。请指导我应该朝哪个方向移动？

【问题讨论】：

这不是也发布在 lessthandot 上吗？

标签： sql-server sql-server-2005 database-design schema database-schema

【解决方案1】：

在这里使用两个单独的表似乎是一种明智的方法 - 这两个表似乎几乎没有共同之处。将不相关的对象组合到一个表中并对不适用的列使用 NULL 通常是一种糟糕的设计。

更一般地说，如果您有两种类型的对象，它们在某些方面不同，但也有一些共同的特征，那么您可以研究的另一种选择是有时称为“表继承”的技术：

在您的第一种方法中，您使用一个包含所有数据的表。在您的第二种方法中，您使用两个完全独立的表。继承方法使用三个表 - 一个用于公共列，一个用于每个专用类型的额外表。然后，您使用外键关系将公用表中的记录与特定表之一中的记录相关联，以便您可以连接以获得完整的对象。我在上面链接的文章中描述了几种不同的方法来创建这种关系。

但不要过度使用表继承。例如，两个表可能碰巧共享几列（ID，insertion_date），但在其他方面是两个概念上不同的东西。那么使用这种技术来分解公共列可能是不合适的。我不太了解您的具体情况，无法说明在“墙帖”和“分享链接”帖子上使用这种技术是否有意义，但您可能需要考虑一下。

举个例子，说明何时使用这种技术而不是拥有两个单独的表会很有用：如果您想查询用户最近的 10 个帖子（无论它们是墙帖还是共享链接），那么它拥有一个表很有用，您可以通过一个简单的查询在其中获取这些帖子的 ID。如果您有两个完全独立的表，它们之间没有任何关系，则查询会更复杂 - 您必须首先从每个表中获取前 10 个，合并结果，然后从联合中获取前 10 个。

【讨论】：

【解决方案2】：

因为这些是独立且不同的项目（墙贴/共享链接/共享视频），每个项目都有自己独特的属性，我建议为每个项目创建一个单独的表。

【讨论】：