2016-05-16 36 views
0

我正在設計一個數據庫來記錄實驗結果。基本上,一個實驗有幾個輸入參數和一個輸出響應。因此,數據表將類似於以下內容:用於記錄實驗數據的數據庫設計

run_id parameter_1 parameter_2 ... parameter_n響應

1 ... ... ... ...

2 ...... ......

。 。 。

但是,該表的結構並不是決定因素,因爲不同的實驗具有不同的列數。然後問題是:當用戶實例化一個實驗時,動態地創建數據表是一個好主意嗎?否則,這是什麼優雅的解決方案?謝謝。

回答

0

當我發現自己試圖在運行時動態創建表時,通常意味着我需要另一個表來解析實體之間的關係。簡而言之,我建議將輸入參數作爲一個單獨的實體處理,並將它們存儲在一個單獨的表中。

這聽起來像你的實體是:

  • 實驗
  • 的實驗運行,這由一個響應和一個或多個:
    • 輸入參數

實體之間的關係是:

  • 一個實驗,以零個或多個運行
  • 一個運行於一個或多個輸入參數值(一對多)

這最後的關係將需要額外的表來解決。您可以有一個存儲輸入參數的單獨表格,並將輸入參數與run_id相關聯。該表可能看起來像:

run_parameter_id ... run_id_fk ... parameter_keyword ... parameter_value 

run_id_fk是一個外鍵在奔跑表中的相應行(在你的問題中所述)。 parameter_keyword僅用於跟蹤參數的名稱(parameter_1_exp1parameter_2_exp1等)。

從數據庫讀取/寫入的查詢現在變得稍微複雜一些(需要連接),但不再依賴於即時創建表。

讓我知道如果這不清楚,我可以提供一個潛在的數據庫圖。

+0

非常感謝您的及時回覆。我一直在四處搜索,發現了類似的解決方案,名爲entity-attribute-value。如上所述,這將創建一個「長而瘦」的表格,並且查詢會變得有點複雜。另一個可能的解決方案是將參數配置存儲爲一個二進制對象BLOB,但是,這不會支持查詢,因此需要一些額外的代碼來遍歷二進制對象。 – Poplong

+0

另一種選擇是以JSON對象的形式將參數存儲在字符串中。您可以使用JSON庫來幫助解析對象,這可能比直接BLOB解析更容易,但是像您提到的那樣仍然需要額外的代碼。 – Michael