2011-03-15 60 views
3

我想在關係數據庫(MySQL或SQLite)中存儲分層的二維科學數據集。每個數據集都包含一個包含任意數量列的數字數據表。另外,每個數據集可以有一個或多個與其表中給定行相關聯的相同類型的子元素。每個數據集通常具有1到100列和1到1.000.000行。數據庫應該能夠處理多個數據集(> 1000),並且數據的讀取/寫入應該相當快。在關係數據庫中存儲科學數據

什麼是最好的DB模式來存儲這種類型的數據?擁有一個帶有單個數據集的名稱,ID和關係的「主表」是否合理?另外每個數據集包含一個包含數值的表格?

+0

什麼是「二維表...有任意數量的列」?你爲什麼不在這裏顯示一些代碼? – 2011-03-15 17:03:30

+0

你想優化什麼?您想通過使用關係數據庫獲得什麼好處? – CookieOfFortune 2011-03-15 17:09:13

+0

一個主要目標是能夠從不同的進程/計算機同時訪問數據(例如,在測量時可視化一組數據)。 – ThePhysicist 2011-03-15 17:20:38

回答

4

是否合理有一個「主」表的名稱,ID和個人數據集的關係,並在每包含的數值數據集除了一個表?

這就是我該怎麼做的。

我不確定'任意列'是如何工作的,因爲數據通常不會像那樣工作。無論如何,它聽起來像將它存儲爲row,col,val可能很好地工作。老實說,如果你不需要搜索它(最大值,最小值等),使用某種平面文件可能會更好。

另一個可能感興趣的設置是使用SQLite,每個數據集都有一個單獨的數據庫文件,另外還有一個主文件夾。

無論你選擇什麼,它的工作效果都取決於你將如何處理數據。

3

我想,你最終會失去對性能的靈活性。 你可以硬編碼你的數據庫模式,這聽起來像你想避免,但會給你最好的性能,或

離開模式確定在運行時,存儲在'主'表,這增加了你的靈活性,但會降低您執行參照完整性和設置數據類型的能力。

有一段時間,你可以嘗試兩種方法,直到你有足夠的信息,哪些會更好地執行你的任務。

2

如果不理解問題域就很難具體,但如果數據本質上是關係型的,則使用關係模型。如果你的數據不是固有的關係數據,我不會試圖強迫它進入關係模型 - 所有數據集碰巧都有一個ID並不意味着這些ID是相同的。或者甚至它們適合用作主鍵。

我建議先將每個數據集放在它自己的表中(或者如果有子記錄的話),然後根據需要創建一個主表。

我會分享zebediah49的問題:「你真的要爲此使用數據庫嗎?平面文件不會更好嗎?」

2

我們在他們自己的平面文件中存儲了一堆這樣的數據。文件頭包含足夠的信息(時間戳,行數/列數等),以便讀取它。然後關於這個數據的元信息在數據庫中。至少這是文件位置,但可能包含有關數據的其他信息。例如,我們將數據彙總到代理變量中,以高層次總結詳細信息。通常情況下,這個彙總數據是足夠好的,但是在必要時我們可以讀取文件中的所有細節。