2012-01-13 58 views
-2

我有一些數據(目前在CSV格式),其爲Ñ -D陣列 - 有Ñ - 尺寸,和一個數據值在每個n各自數據點尺寸爲。所有架構解決方案我來爲存儲該陣列是空間效率不高 - 例如,爲2d中的顯而易見的解決方案:表示DB的ND陣列有效地

Table ArrayData 
---------------- 
id 
row 
column 
dataValue 

佔用O(N^2)空間,並且類似地使用Nd陣列需要O( N^N)空間。因爲我知道rowcolumn的大小和形狀是什麼(它們只是從0到任何的範圍),我覺得我應該只需要存儲iddataValue - 數據的順序應該足夠,類似於數據一個n -D數組存儲在C中的內存中。

我可以定義索引到數組和索引到數組的函數 - 但是這看起來有點過度消耗。我錯過了明顯嗎?有這種事情的預定義的SQL函數嗎?

回答

1

對於傳統的關係型數據庫設計,我們並沒有考慮維度。我們通常根據對象來思考。您可能會進入雜草 - 只是因爲您將數據存儲在代碼中的多維數組中並不意味着您的數據庫模式應該反映該數據。這就是說,有很多時候在尺寸方面進行思考,特別是OLAP(多維數據庫設計)。通常,這些模式是爲報告目的而構建的,可以從大量數據中快速檢索和聚合數據。他們對查詢不友好,他們可以允許錯誤的數據,但是他們在做什麼時非常高效。

如果我想存儲3維的字符串。

SOME_VALUE_FACT 
---------------- 
X_DIM_ID int (FK) 
Y_DIM_ID int (FK) 
Z_DIM_ID int (FK) 
THE_STRING_BEING_STORED varchar(200) 

X_DIM 
-------------- 
X_DIM_ID int (PK) 
X_DIM_VALUE 

(Y, and Z tables are similar) 
+0

謝謝,我收到您對物體和傳統數據存儲的評論 - 您是否瞭解其他技術?我仍然希望儘可能有效地堅持這些數據。你描述的'FK'是'int',所以存儲空間仍然是O(N^N)否? – danodonovan 2012-01-13 22:04:37

+0

我不確定你的意思?您的選擇是不規範化並將所有值全部保存在一個表中(複製記錄)或使用外鍵。如果你試圖存儲的數據實際上是整數,那麼你不會通過規範化來保存任何空間(這也許是你問的問題?)。如果你只打算使用更小的整數,你可以嘗試使用更小的數據類型(16位整數?),但是你的增長會受到很大限制。 – Arbiter 2012-01-17 15:16:09