父/子关系表设计 - 最佳实践是什么？

Question

我有一个用于存储“任务”的表。任务可以是父项和/或子项。我使用“ ParentID ”作为 FK 引用同一张桌子上的 PK。它是 NULLABLE，所以如果它是NULL它没有父任务。

示例是下面的屏幕截图...

在我的团队中，有人认为创建一个单独的表来存储 ParentID 会更好（对于规范化/最佳实践），从而避免表中出现 NULL 并导致更好的规范化设计。

这会是一个更好的选择吗？或者查询会更困难并导致性能问题？

我们只想从一开始就做好设计，而不是以后再发现问题。

现有表的 SQL-DDL 代码：

CREATE TABLE [Tasks].[TaskDetail]
(
    [TaskDetailID] [int] IDENTITY(1,1) NOT NULL,
    [TaskName] [varchar](50) NOT NULL,
    [TaskDescription] [varchar](250) NULL,
    [IsActive] [bit] NOT NULL CONSTRAINT [DF_TaskDetail_IsActive] DEFAULT ((1)),
    [ParentID] [int] NULL,
    CONSTRAINT [PK_TaskDetail_TaskDetailID] PRIMARY KEY CLUSTERED ([TaskDetailID] ASC),
    CONSTRAINT [FK_TaskDetail_ParentID] FOREIGN KEY([ParentID]) REFERENCES [Tasks].[TaskDetail]([TaskDetailID])
);

Answer 1

您描述的用于表示任务层次结构的技术称为“邻接列表”。尽管它对人类来说是最直观的，但它并不适合在 SQL 中进行非常有效的查询。其他技术包括路径枚举（又名物化路径）和嵌套集。要了解其他一些技术，请阅读这篇文章或在网络上搜索有关这些技术的大量文章。

SQL Server为路径枚举提供了本机层次结构表示。这很可能是你最好的选择......