Question

因此，我最近的任务是使用C＃将旧的平面文件系统调度系统转移到SQL数据库中。

我发现的主要问题是任务（参见下面的代码段）使用字符串列表（使用GUID创建）使我不确定如何构建数据库。

public class Task
{
      private string TaskID;

      private string TaskName;
      private string TaskDescription;

      private bool IsComplete;

      private DateTime EstimatedStartDate;
      private DateTime ActualStartDate;

      private DateTime EstimatedCompletionDate;
      private DateTime ActualCompletionDate;

      private string TeamLead;
      private List<string> TeamMembers = new List<string>();

      private TaskType TaskType;
      private string ParentID;
      private List<string> ChildIDs = new List<string>();
}

说到SQL，我知道使用只能包含在单个Cell中的列表通常是nono。

真正的问题是：我是否应该在列表中查询，查询只需要查询taskID或parentID以查找请求的任务，或者将其拆分为系统中每个类别的不同表（这样可行在4个不同的类别中）然后依赖于任务的类型和taskID来选择它需要查询其子项的正确表。

Answer 1

如果使用半正式语法更清楚地定义问题域，则会有所帮助。解释您的代码片段，我认为归结为以下几点。

A task is identified by TaskID
A task has attributes name, description etc.
A task has exactly one person, in the role "TeamLead".
A task has 0 or more persons, in the role "team member".
A task has exactly one type, selected from a collection of valid types.
A task may or may not have a relationship to another task, in the role ParentTask
A task has a relationship with 0 or more other tasks, in the relationship "childTask".

如果这是真的，你可以看到关系模型的出现。

通常，任何有“x..n”连接的关系都会导致桥接表。在您的情况下，这是“TeamMembers”，其中TaskID和PersonID为外键。 ChildTasks是一种类似的关系。

在“只有一个”或“可能有一个”的情况下，它是外键。 TeamLead和TaskType就是例子。

绝对没有理由为任务类型创建不同的表 - 关系模型鼓励您将类似的事物组合在一起，并通过数据而不是结构来区分它们。

Answer 2

具有相同结构和相同含义的多个表是一个强大的反模式：您必须修改所有查询以访问正确的表（如果您想要汇总来自多个类别的数据，这会变得特别复杂），您会每当可能的类别集发生变化时，都必须修改数据库结构。不太可能存在任何可测量的（更不用说明显的）性能差异。

换句话说，永远不要将数据放入表名。

我应该为每个类别创建单独的表吗？

2 个答案: