database - 如何在 SQL Server 2008 中优化存储以下 SQL 数据

Question

我正在创建一个人们可以发布文章的页面。当用户发布文章时，它会显示在列表中，例如 Stack Overflow 上的相关问题(当您添加新问题时)。这相当简单。

我的问题是我有两种类型的用户。 1) 未注册的私有(private)用户。 2) 公司。

未注册用户需要输入姓名、邮箱和电话。而公司用户只需要输入他们的公司名称/密码。相当简单。

我需要减少过多的数据库使用，并尝试优化数据库并有效地构建表。

现在我手头的问题:

所以我有一张表，其中包含有关公司的信息、ID (guid)、姓名、电子邮件、电话 等。

我正在考虑创建一个名为 articles 的表，其中包含 ArticleID、标题、内容和发布日期。

一张表，包含未注册用户的信息、ID、姓名、电子邮件和电话。

如何将文章表绑定(bind)到公司/未注册用户表。制作一个包含 2 个值的整数是否很好，1 = 未注册用户和 2 = 公司，然后是一个带有指定用户/公司 ID 号的字段。看起来你需要很多额外的代码来查询数据库。表现？那么我怎么能把文章连同联系信息一起退回呢？您还应该能够退回特定公司的所有文章。

所以表公司将是:

ID (guid), company name, phone, email, password, street, zip, country, state, www, description, contact person and a few more that i don't have here right now.

表未注册用户:

ID (guid), name, phone, email

表格文章:

ID (int/guid/short guid), headline, content, published date, is_company, id_to_user

有没有更好的方法？

我正在寻找的品质是:性能、易于查询和易于维护(添加新字段、索引等)

Answer 1

理论

您描述的问题在数据建模理论中称为表继承。在 Martin Fowler 的书中，解决方案是:

• single table inheritance :包含所有字段的单个表。
• class table inheritance : 每个类一个表，抽象类表。
• concrete table inheritance : 每个非抽象类一个表，抽象成员在每个具体表中重复

所以从理论和行业实践的角度来看，所有三种解决方案都是可以接受的:一张表 Posters 的列为 NULLable 列(即单表)，三张表 Posters、Companies 和 Persons(即类继承)和两张表 Companies和 Persons(即具体继承)。

现在，利弊。

NULL 列的成本

记录结构在Inside the Storage Engine: Anatomy of a record中讨论。 :

NULL bitmap

• two bytes for count of columns in the record
• variable number of bytes to store one bit per column in the record, regardless of whether the column is nullable or not (this is different and simpler than SQL Server 2000 which had one bit per nullable column only)

因此，如果您至少有一个 NULLable 列，您将支付每条记录中 NULL 位图的成本，至少 3 个字节。但如果您有 1 列或 8 列，成本相同!第 9 个 NULLable 列将向每个记录中的 NULL 位图添加一个字节。 Estimating the Size of a Clustered Index 中描述了该公式: 2 + ((Num_Cols + 7)/8)

性能驱动因素

在数据库系统中，实际上只有一个驱动性能的因素:扫描的数据量。一个查询计划扫描的记录有多大，它要扫描多少条记录。因此，要提高性能，您需要:

• narrow the records:减少数据大小，覆盖include索引，垂直分区
• 减少扫描记录的数量:索引
• 减少扫描次数:消除连接

现在为了分析这些标准，您的帖子中缺少一些东西:流行的数据访问模式，即。数据库将被命中的最常见查询。这取决于您在网站上显示帖子的方式。考虑这些可能的方法:

• posts front page:像 SO，最近的帖子页面，包含标题、摘录、发布时间和作者基本信息(姓名、头像)。要显示此页面，您需要加入 Posts with authors，但您只需要作者姓名和头像。单表继承和类表继承都可以，但具体表继承会失败。这是因为您无法承受这样的查询来进行条件联接(即联接发布给公司 或 人员的文章)，这样的查询将不是最佳的。

  <

• 每个作者的帖子:用户必须先登录，然后他们才能看到自己的帖子(这对于非公开的面向帖子的网站很常见，例如事件跟踪)。对于这样的设计，所有三种表继承方案都适用。

结论

有一些一般的性能注意事项(即缩小数据范围)需要考虑，但缺少关键信息:您将如何查询数据、您的访问模式。必须针对访问模式优化数据模型:

• Companies 和 Persons 的哪些字段将显示在网站的着陆页上(即最常见且性能关键的查询)？您不想连接 5 个表来显示那些 字段。
• 某些公司/个人信息字段是否仅在用户信息页面上需要？也许将表垂直划分为 CompaniesExtra 和 PersonsExtra 表。或者使用覆盖常用字段的索引(这种方法简化了代码并且更容易保持一致，但代价是数据重复)

附言

不用说了， don't use guids for ids 。除非您要构建分布式系统，否则由于宽度过大，它们是一个糟糕的选择。碎片也是一个潜在的问题，但可以通过使用顺序 guid 来缓解。