我的表列出了待办事项。每个都包含一个特定任务,该任务需要先完成某些先决条件(其他任务(,然后才能处理待办事项。它目前使用一个简单的计数器(即最初设置为特定数字,并且每个完成的先决条件将其减少 1(。
tasks:
id, task
1, A
2, B
3, C
todos:
id, user_id, task_id, prerequisites
1, 1, 1, 3
2, 1, 2, 2
3, 2, 1, 3
我现在还想确定哪些任务是先决条件,因此想到了以下解决方案,使用任务的二进制递增标识符:
tasks:
id, task, prerequisite_id
1, A, 1
2, B, 2
3, C, 4
todos:
id, user_id, task_id, prerequisites
1, 1, 1, 7
2, 1, 2, 2
3, 2, 1, 5
我现在可以说待办事项仍然需要处理任务 1,2,3。而 2 需要任务 2,3 需要任务 1 和 3。
我知道多对多表将是最佳实践解决方案,但是上述方法是一个坏主意有什么特殊原因吗?
编辑:能够查询先决条件列并不重要。我只想知道列何时为 0。我只在极少数情况下检查实际值。
一个好主意,因为:
想象一下,有超过 64 个任务或待办事项。突然间,您的数据不再适合int64
,因为prerequisite_id将高于 264,这是您可以存储在数值类型的可索引列中的最大值。你必须开始使用二进制数据列,一般来说,使用 bignums 编程是一件非常混乱的事情,你应该尽量避免它,除非你正在处理一个必要的主题。
如果使用常规int32
或int64
列,则值可能会溢出,并且即使该值实际上不为零,加法也可能导致0
结果。根据您的实现,id 高于 63 的任何关系都将被忽略,或者 id 可被整数整除的任何关系将被 64 整除。
这两种情况都可能是不需要的。
MySQL为类似的工作提供了一种数据类型,称为SET数据类型。唯一的区别是,在解决方案中不必定义集合。您只需假设位对应于任务 ID。
如@aphid所述,如果执行此操作,您将无法拥有超过 63 的任何任务 ID(在 SET 数据类型中,您仍然限制为 64 个可能的条目,但它们的值可以是任何内容(。
我建议使用多对多表。它更加灵活。