在关系数据库中使用列表可以吗？

我一直在尝试设计一个与项目概念相适应的数据库，并遇到了一个似乎引起激烈争论的问题。我已经阅读了几篇文章和一些Stack Overflow的答案，指出永远（或几乎永远）无法在字段中存储ID或类似内容的列表-所有数据都应该是相关的，等等。

不过，我遇到的问题是我正在尝试创建任务分配器。人们将创建任务，将其分配给多个人，并将其保存到数据库中。

当然，如果我将这些任务分别保存在“人员”中，则必须有几十个虚拟的“任务ID”列并对其进行微管理，因为可以将0到100个任务分配给一个人。

再一次，如果我将任务保存在“任务”表中，则必须有几十个虚拟的“ PersonID”列并对其进行微管理-与以前一样的问题。

对于这样的问题，是否可以保存采用一种形式或另一种形式的ID列表，或者我只是不考虑另一种可以在不违反原则的情况下实现的方式？

您需要研究的关键词和关键概念是数据库规范化。

您要做的不是向人员或任务表添加有关分配的信息，而是向该表添加具有相关关系的分配信息的新表。

例如，您具有下表：

人数：

+---+----------+
| ID | 姓名|
+ ==== + ========== +
| 1 | 阿尔弗雷德|
| 2 | 杰比迪亚|
| 3 | 雅各布|
| 4 | 以西结书
+---+----------+

任务：

+---+-------------
| ID | 姓名|
+ ==== + ================== +
| 1 | 喂鸡
| 2 | 犁|
| 3 | 奶牛|
| 4 | 养一个谷仓|
+---+-------------

然后，您将使用赋值创建第三个表。该表将模型化人员与任务之间的关系：

+---+----------+----+
| ID | PersonId | TaskId |
+ ==== + =========== + ======== +
| 1 | 1 | 3 |
| 2 | 3 | 2 |
| 3 | 2 | 1 |
| 4 | 1 | 4 |
+---+----------+----+

然后，我们将具有外键约束，以便数据库将强制PersonId和TaskId必须是那些外来项的有效ID。第一行，我们可以看到PersonId is 1，所以阿尔弗雷德，被分配到TaskId 3，挤奶。

您应该在这里可以看到的是，每个任务或每个人可以根据需要分配少或多的任务。在此示例中，没有为以西结（Ezekiel）分配任何任务，并且为Alfred分配了2个任务。如果您有一个有100个人的任务，那么执行SELECT PersonId from Assignments WHERE TaskId=<whatever>;将产生100行，并分配了各种不同的个人。您可以WHERE在PersonId上查找分配给该人的所有任务。

如果您想返回用名称和任务替换ID的查询，那么您将学习如何联接表。

您在这里问两个问题。

首先，您询问是否可以存储在列中序列化的列表。是的，很好。 如果您的项目需要它。 一个示例可能是目录页面的产品成分，您不希望尝试单独跟踪每种成分。

不幸的是，您的第二个问题描述了一个场景，您应该选择一种更相关的方法。您将需要3张桌子。一个用于人员，一个用于任务，另一个维护将哪些任务分配给哪些人员的列表。最后一个将是垂直的，每人/任务组合一行，主列，任务ID和人员ID的列。

您所描述的是所谓的“多对多”关系，在您Person和之间Task。通常使用第三个表（有时称为“链接”或“交叉引用”表）来实现。例如：

create table person (
    person_id integer primary key,
    ...
);

create table task (
    task_id integer primary key,
    ...
);

create table person_task_xref (
    person_id integer not null,
    task_id integer not null,
    primary key (person_id, task_id),
    foreign key (person_id) references person (person_id),
    foreign key (task_id) references task (task_id)
);

...永远（或几乎永远）无法在字段中存储ID或类似内容的列表

唯一可能在一个字段中存储多个数据项的时间是该字段仅用作单个实体，并且永远不认为该字段由那些较小的元素组成。一个示例可能是存储在BLOB字段中的图像。它由很多较小的元素（字节）组成，但是这些元素对数据库没有任何意义，只能一起使用（对于最终用户来说看起来很漂亮）。

根据定义，“列表”由较小的元素（项目）组成，因此情况并非如此，您应该对数据进行规范化。

...如果我将这些任务分别保存在“人员”中，则必须有几十个虚拟的“任务ID”列...

不会。在“人”与“任务”之间的相交表（又称为“弱实体”）中将有几行。数据库真的很擅长处理很多行。在处理许多[重复]列时，它们实际上是很垃圾的。

whatsisname给出的很好的清晰示例。

在某些预先计算的字段中可能是合法的。

如果您的某些查询价格昂贵，并且您决定使用数据库触发器自动更新预先计算的字段，那么将列表保留在列中可能是合法的。

例如，在用户界面中，您想使用网格视图显示此列表，双击后，每一行都可以打开完整的详细信息（带有完整的列表）：

REGISTERED USER LIST
+------------------+----------------------------------------------------+
|Name              |Top 3 most visited tags                             |
+==================+====================================================+
|Peter             |Design, Fitness, Gifts                              |
+------------------+----------------------------------------------------+
|Lucy              |Fashion, Gifts, Lifestyle                           |
+------------------+----------------------------------------------------+

当客户访问新文章或计划任务时，您将通过触发器来更新第二列。

您甚至可以将此类字段用于搜索（作为普通文本）。

在这种情况下，保留清单是合法的。您只需要考虑可能超过最大字段长度的情况。

另外，如果您使用的是Microsoft Access，则提供的多值字段是另一个特殊的用例。他们会自动处理您在字段中的列表。

但是您总是可以退回到其他答案中所示的标准规范化形式。

简介：标准形式的数据库是理解数据建模重要方面所需的理论模型。但是，归一化当然不会考虑性能或检索数据的其他成本。这超出了该理论模型的范围。但是实际实现通常需要存储列表或其他预先计算（和控制）的副本。

鉴于上述情况，在实际实现中，我们是否希望查询依赖于完美的范式并运行20秒或等效查询依赖于0.08 s的预先计算的值？没有人喜欢他们的软件产品被指责缓慢。

给定两个表；我们将它们称为Person和Task，每个都有其自己的ID（PersonID，TaskID）...基本思想是创建第三个表以将它们绑定在一起。我们将此表称为PersonToTask。至少，它应该有自己的ID，以及其他两个ID。您将不再需要更新Person表，只需要在PersonToTaskTable中插入新行即可。而且维护变得更加容易-只需删除一个任务就可以成为基于TaskID的DELETE，而无需再更新Person表及其关联的解析

CREATE TABLE dbo.PersonToTask (
    pttID INT IDENTITY(1,1) NOT NULL,
    PersonID INT NULL,
    TaskID   INT NULL
)

CREATE PROCEDURE dbo.Task_Assigned (@PersonID INT, @TaskID INT)
AS
BEGIN
    INSERT PersonToTask (PersonID, TaskID)
    VALUES (@PersonID, @TaskID)
END

CREATE PROCEDURE dbo.Task_Deleted (@TaskID INT)
AS
BEGIN
    DELETE PersonToTask  WHERE TaskID = @TaskID
    DELETE Task          WHERE TaskID = @TaskID
END

一个简单的报告或分配给谁的任务怎么样？

CREATE PROCEDURE dbo.Task_CurrentAssigned (@TaskID INT)
AS
BEGIN
    SELECT PersonName
    FROM   dbo.Person
    WHERE  PersonID IN (SELECT PersonID FROM dbo.PersonToTask WHERE TaskID = @TaskID)
END

您当然可以做更多的事情；如果您为TaskAssigned和TaskCompleted添加了DateTime字段，则可以完成TimeReport。这一切都取决于你

如果说您具有人类可读的主键并且想要任务列表，而不必处理表结构的垂直性质，那么它可能会起作用。即更容易阅读第一张桌子。

------------------------  
Employee Name | Task 
Jack          |  1,2,5
Jill          |  4,6,7
------------------------

------------------------  
Employee Name | Task 
Jack          |  1
Jack          |  2
Jack          |  5
Jill          |  4
Jill          |  6
Jill          |  7
------------------------

那么问题将是：任务列表是否应按需存储或生成，这在很大程度上取决于以下要求：列表需要多久一次，存在多少数据行的准确性，如何使用数据等。 ..之后，应分析用户体验和满足要求之间的权衡。

例如，比较调用两行所需的时间与运行将生成两行的查询所需要的时间。如果花费时间很长，并且用户不需要最新列表（*预计每天少于1次更改），则可以将其存储。

或者，如果用户需要分配给他们的任务的历史记录，则也可以使用列表的存储方式。因此，这实际上取决于您在做什么，永远不要说永远。

您正在拿应该是另一张桌子的东西，将它旋转90度，然后将它拔成另一张桌子。

就像有一个订单表，其中有itemProdcode1，itemQuantity1，itemPrice1 ... itemProdcode37，itemQuantity37，itemPrice37。除了笨拙地以编程方式处理之外，您还可以保证明天某人将要订购38件商品。

如果“列表”不是真正的列表，我只会按照您的方式进行操作，也就是说，它作为一个整体存在，并且每个单独的订单项都未引用某个清晰且独立的实体。在这种情况下，只需将其填充为足够大的某种数据类型即可。

因此，订单是一个清单，物料清单是一个清单（或清单的清单，这对于实施“侧身”而言将是一场噩梦）。但不是注释/注释和诗歌。

如果“不行”，那么每个Wordpress网站都在wp_usermeta中有一个列表，其中有wp_capabilities排成一行，dismissed_wp_pointers列表排成一行，等等是非常糟糕的。

实际上，在这种情况下，速度可能会更好，因为您几乎总是需要列表。但是，众所周知，Wordpress并不是最佳实践的完美范例。