我需要创建一个表，每个用户（大约60 atm）将有一个定义的任务，每天。现在的数据库有一个列，每个用户的任务名称在它（这在我看来是不好的，因为每个新用户将需要改变表的方案）和一个“日期”列。一个解决方案是有一个“user”列并添加一个“task”列，但这意味着每天将有60行（当前用户的数量）。我真的不知道在这种情况下什么是最好的。
ar7v8xwq1#
我应该使用更多的列还是更多的行？它们是两个完全不同的东西，所以这种比较没有多大意义......目前，数据库中每个用户都有一列坏主意。句号。* user * 是数据记录，而不是数据库本身的结构元素。例如，用户表可能包含Username、Email、RegistrationDate等列。它不会是为每个新用户 * 添加一列 * 的单行数据。这将是一场维护的噩梦，会使外键之类的东西变得无用（老实说，会使 * 关系数据库 * 的整个概念变得无用），会 * 很快 * 达到资源限制，等等。每条信息记录都是一个 * 行 *，而不是一个 * 列 *（或 * 表 *）。在这种情况下，表中的每个 * 行 * 都是一个"用户任务"。它定义（或具有指向）用户的外键，并定义（或具有指向）任务的外键。但这意味着每天将有60（当前用户数）行如果表中的记录数量开始成为问题，您可以开始考虑分片和分区、归档旧数据等问题。不过您还有时间，因为"每天几十条记录"可以持续数千年（我想到那时硬件至少会比现在好两倍）。
ih99xse12#
现在数据库中每个用户都有一列任务名称（我认为这很糟糕，因为每个新用户都需要〉来更改表的方案）你说得对，这是非常糟糕的。用一列表示用户，一列表示任务，一列表示日期会更好。每天60行并不多，这意味着每年21. 900行，十年21. 900行。Mysql能够处理一个表中数百万行如果你有两个索引，一个用于user，一个用于date，那么搜索数据就会足够快。
fd3cxomn3#
如果对数据库或模式一无所知，为什么不创建一个维度表来存储用户，创建一个事实表来跟踪任务细节呢？这样，您就可以更轻松地添加新用户，任务表将随着新事实的添加而继续增长，同时也很容易为了查询和/或报告的目的而对该模型进行非规范化。
3条答案
按热度按时间ar7v8xwq1#
我应该使用更多的列还是更多的行？
它们是两个完全不同的东西，所以这种比较没有多大意义......
目前，数据库中每个用户都有一列
坏主意。句号。* user * 是数据记录，而不是数据库本身的结构元素。例如，用户表可能包含Username、Email、RegistrationDate等列。它不会是为每个新用户 * 添加一列 * 的单行数据。
这将是一场维护的噩梦，会使外键之类的东西变得无用（老实说，会使 * 关系数据库 * 的整个概念变得无用），会 * 很快 * 达到资源限制，等等。
每条信息记录都是一个 * 行 *，而不是一个 * 列 *（或 * 表 *）。在这种情况下，表中的每个 * 行 * 都是一个"用户任务"。它定义（或具有指向）用户的外键，并定义（或具有指向）任务的外键。
但这意味着每天将有60（当前用户数）行
如果表中的记录数量开始成为问题，您可以开始考虑分片和分区、归档旧数据等问题。不过您还有时间，因为"每天几十条记录"可以持续数千年（我想到那时硬件至少会比现在好两倍）。
ih99xse12#
现在数据库中每个用户都有一列任务名称（我认为这很糟糕，因为每个新用户都需要〉来更改表的方案）
你说得对，这是非常糟糕的。用一列表示用户，一列表示任务，一列表示日期会更好。
每天60行并不多，这意味着每年21. 900行，十年21. 900行。Mysql能够处理一个表中数百万行如果你有两个索引，一个用于user，一个用于date，那么搜索数据就会足够快。
fd3cxomn3#
如果对数据库或模式一无所知，为什么不创建一个维度表来存储用户，创建一个事实表来跟踪任务细节呢？
这样，您就可以更轻松地添加新用户，任务表将随着新事实的添加而继续增长，同时也很容易为了查询和/或报告的目的而对该模型进行非规范化。