在复杂系统中，拥有与多个实体相关的通用子系统是很常见的。一个示例可能是工作流引擎，其中“申请单”，“作业”和“评估”可能各自都有自己的工作流程。
有些甚至可能有> 1个链接到子系统，例如表单引擎，用户可能有个人详细信息表单和员工历史表单。
您甚至可以考虑将日志记录为子系统，其中实体可以有多个日志记录。
有几种方法可以模拟这种“上下文”，一种是使用KVP样式：
CREATE TABLE工作流（WorkflowID，ContextObject varchar（20），ContextKey int），其中ContextObject包含“Job”，“User”，“Assessment”和ContextKey，可以是JobID，UserID，AssessmentID等。< / p>
另一种方法是使用具有可空列的更宽表，例如
CREATE TABLE工作流（WorkflowID，JobID INT NULL，UserID INT NULL，AssessmentID INT NULL）
上下文键互斥。
我想知道从性能的角度来看哪种方法“更好”，尤其是当行数增加到数十万到数百万时？
KVP样式表将以更窄的行（更大的表）结束，可空列方法具有更宽的行，但是可以在这些行上构建单独的索引。使用SQL Server，我们可以使用Filtered Indexes为每个上下文创建索引，其中contextID不为null。
使用nullable-column方法可以为optmizer提供更好的统计信息 - 即，如果它是基于JobID的连接，那么优化器将知道该表中的100万行，只有10,000与jobID相关。
我想知道人们对两种不同方法的看法。
假设每个上下文都提供了相当高的基数（每种上下文类型几乎为1）。还假设最新版本的SQL Server。