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