SQL Server 架构审查

Question

我正在构建一个支持用户之间不同类型消息的 MVC Web 应用程序。例如，一些消息与 RFP 相关联，而其他消息与发票相关联。将来我们可能会被要求支持其他消息类型。

所以这是我到目前为止提出的架构。

消息线程

Id                 int              PK

留言

Id                 int              PK
MessageThreadId    int              FK
UserId             uniqueidentifier FK
Subject            nvarchar(250)
Text               nvarchar(max)
DateCreated        datetime

RFPMessageThread

RFPId              int              PK/FK
MessageThreadId    int              PK/FK

InvoiceMessageThread

InvoiceId          int              PK/FK
MessageThreadId    int              PK/FK

这应该可行，但我质疑这是否是最佳路线。显然，如果我只有一种消息类型，我可以消除 MessageThread 表。

有什么建议、建议、批评吗？

Answer 1

这是经典的表继承模式问题，有 3 个已建立的解决方案：

• Concrete Table Inheritance
• Single Table Inheritance
• Class Table Inheritance

每个人都有优点和缺点。您选择了类表继承，这是大多数开发人员自然倾向于做的事情，因为它遵循代码的设计模型并且看起来是规范化的。但性能更差，因为它需要频繁的连接、插入和更新，成本高昂，并且数据完整性执行很复杂。我非常喜欢单表继承模型：一个且只有一个表，[Messages]，因为它在最频繁的访问模式中的简单性和运行时性能（例如，显示我的“收件箱”是一个简单而快速的查询）。我建议您在负载下并使用合理的大型数据集对您提出的模型进行一些测试。