针对多列相同数据模式的数据库设计

Question

如果我错误地使用了“数据模式”，我表示歉意。这里有一些背景。我将Access数据库移植到基于Web的MYSQL应用程序。以下是我们正在追踪的内容。

我们有一台最多16个机头的机器。每个头都有三个与其相关的项目，其中两个是整数，一个是短文本字符串。每个生产订单至少使用一个头。有些使用全部16个，有些仅使用一个。如果使用多个头，我们会跟踪它们的使用顺序。每个生产订单都有几个短到中等长度的字段，另外还存储这些字段。绝大多数生产运行使用不到给定头的一半。

当前数据位于Access数据库中，该数据库将所有内容存储在一个表中，因此每行存储6 +（16 * 3）48个字段，总共包含54列。唯一的搜索字段是第二个，它们是整数。

id|workorder|partnumber|note|machine|reference|head1spec1|head1spec2|head1spec3|head2spec1|head2spec2|head2spec3| ...等，以头16

我知道有很多的死亡空间在那里，因为每一行包含16种元素，可以被分解成一个单独的表，并加入了显示效果。它已经获得了大约10年的数据，现在Access数据库的文件大小为60.8 MB

这是我的问题。在这种情况下，是否有任何真正的世界优势来规范化（可能不正确的用法），因为没有这些数据用于搜索，并且将它全部放在一列中对于该​​信息来说是一种自然状态？

Answer 1

是的，有真实世界的优点，但我认为它们不足以保证修改现有的Access架构。相反，如果可能的话，我会把精力转移到一个更好的平台上，例如，基于Web的SQL Server后端。在进行迁移时您可以担心模式。

归一化的架构将帮助之类的东西：

• 数据完整性：保证同一头或头规格不是同一台机器上使用了两次（除非是有效的，当然...）
• 查询：很容易计算什么是最常用的headpec

你可以用你现在的模式来做这些事情，它只需要更多的工作。但是，这种模式已经运行了10年，那么变化的商业案例是什么？

Answer 2

我知道有很多的死亡空间在那里，...

不是真的。我并不了解Access如何实现它，但大多数数据库在存储NULL（通常是一个字节，但可能低至一位，如MS SQL Server的情况下）中相当有效。

...因为每行包含16个元素，可以将其分解为一个单独的表格并加入以显示结果。它已经获取的数据了约10年，现在的Access数据库文件的大小为60.8 MB

你没有说有多少行了这10多年积累，但60.8 MB是数据库方面花生，即使对于“轻量级”数据库（如Access）也是如此。

空间不是你的问题，因为整个数据库很容易适应当今硬件的内存（甚至10年前的硬件），速度也可能不是你的问题。

这是我的问题。在这种情况下，是否有任何真正的世界优势来规范化（可能不正确的用法），因为没有这些数据用于搜索，并且将它全部放在一列中对于该​​信息来说是一种自然状态？

优势（分裂从事1的两个表：N的关系）是更好的灵活性的情况下，你需要支持不同的机器有不同数量的头。此外，编写查询搜索，汇总或平均数据在所有头可能会更简单。

缺点是需要更多空间（因为子表需要存储来自父表的PK值的副本）并且更需要JOINing。

总而言之，您现有的设计对我来说看起来很好。你有没有在你的问题中提到你想要解决的具体问题？