針對多列相同數據模式的數據庫設計

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。

總而言之，您現有的設計對我來說看起來很好。你有沒有在你的問題中提到你想要解決的具體問題？