如果我错误地使用“数据模式”，我道歉。这是一些背景知识。我正在将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 DB的文件大小是60.8 MB
这是我的问题。在这种情况下，规范化（可能是不正确的用法）是否有任何现实世界的优势，因为没有一个数据用于搜索，并且将所有数据都放在一列中对于该信息是一种自然状态？
答案 0 :(得分：1)
是的，有现实世界的优势，但我认为它们不足以保证修改您现有的Access架构。相反，如果可能的话，我会将精力投入到更好的平台，例如，基于Web的SQL Server后端。在进行迁移时，您可以担心架构。
规范化架构将有助于实现：
您可以使用现在拥有的架构来完成这些工作，只需要更多工作。但是，这个模式已经工作了10年，那么变革的商业案例是什么？
答案 1 :(得分：1)
我知道那里有很多死角，......
不是真的。我不知道Access如何做到这一点，但是大多数数据库在存储NULL方面都非常有效（通常是一个字节，但可能只有一位，就像MS SQL Server一样）。
...因为每行包含16个元素，这些元素可以分解为单独的表并连接到显示结果。它已经获取了大约10年的数据，现在Access DB的文件大小是60.8 MB
你没有说这10年累积了多少行，但数据库中60.8 MB是花生，即使对于像Access这样的“轻型”数据库也是如此。
空间不是你的问题，因为整个数据库很容易适应当今硬件（甚至是10年前的硬件）的内存，速度可能不是你的问题。
这是我的问题。在这种情况下，规范化（可能是不正确的用法）是否有任何现实世界的优势，因为没有一个数据用于搜索，并且将所有数据都放在一列中对于该信息是一种自然状态？
如果您需要支持具有不同磁头数的不同机器，则优势（分成两个参与1：N关系的表）将具有更好的灵活性。此外，编写在所有头上搜索，总结或平均数据的查询可能更简单。
缺点是需要更多空间（因为子表需要存储来自父表的PK值的副本），并且需要更多的JOINing。
总而言之，您现有的设计对我来说很好。您在试图解决的问题中没有提到任何具体问题吗？