1

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

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

目前，数据位于一个将所有内容存储在一个表中的 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

这是我的问题。在这种情况下，规范化（可能不正确的使用）是否有任何现实世界的优势，因为没有任何数据用于搜索，并且将所有数据放在一列中是该信息的一种自然状态？

4

2 回答 2

1

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

规范化的模式将有助于解决以下问题：

  • 数据完整性：确保相同的头部或头部规格不会在同一台机器上使用两次（当然，除非那是有效的......）
  • 查询：轻松统计最常用的headspec是什么

你可以用你现在拥有的模式来做这些事情，只是需要多做一点工作。但是，这个模式已经工作了 10 年，那么改变的商业案例是什么？

于 2012-10-29T19:52:42.047 回答
1

我知道那里有很多死角，...

并不真地。我不知道 Access 是如何做到的，但大多数数据库在存储 NULL 方面相当有效（通常是一个字节，但可能低至一位，就像MS SQL Server的情况一样）。

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

您没有说这 10 年累积了多少行，但 60.8 MB 在数据库方面是微不足道的，即使对于 Access 这样的“轻型”数据库也是如此。

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

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

如果您需要支持具有不同数量的磁头的不同机器，则优势（拆分为参与 1:N 关系的两个表）将具有更好的灵活性。此外，编写在所有头部搜索、求和或平均数据的查询可能更简单。

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

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

于 2012-10-29T22:10:12.610 回答