我正在設計一個數據庫來記錄實驗結果。基本上,一個實驗有幾個輸入參數和一個輸出響應。因此,數據表將類似於以下內容:用於記錄實驗數據的數據庫設計
run_id parameter_1 parameter_2 ... parameter_n響應
1 ... ... ... ...
2 ...... ......
。 。 。
但是,該表的結構並不是決定因素,因爲不同的實驗具有不同的列數。然後問題是:當用戶實例化一個實驗時,動態地創建數據表是一個好主意嗎?否則,這是什麼優雅的解決方案?謝謝。
我正在設計一個數據庫來記錄實驗結果。基本上,一個實驗有幾個輸入參數和一個輸出響應。因此,數據表將類似於以下內容:用於記錄實驗數據的數據庫設計
run_id parameter_1 parameter_2 ... parameter_n響應
1 ... ... ... ...
2 ...... ......
。 。 。
但是,該表的結構並不是決定因素,因爲不同的實驗具有不同的列數。然後問題是:當用戶實例化一個實驗時,動態地創建數據表是一個好主意嗎?否則,這是什麼優雅的解決方案?謝謝。
當我發現自己試圖在運行時動態創建表時,通常意味着我需要另一個表來解析實體之間的關係。簡而言之,我建議將輸入參數作爲一個單獨的實體處理,並將它們存儲在一個單獨的表中。
這聽起來像你的實體是:
實體之間的關係是:
這最後的關係將需要額外的表來解決。您可以有一個存儲輸入參數的單獨表格,並將輸入參數與run_id
相關聯。該表可能看起來像:
run_parameter_id ... run_id_fk ... parameter_keyword ... parameter_value
凡run_id_fk
是一個外鍵在奔跑表中的相應行(在你的問題中所述)。 parameter_keyword
僅用於跟蹤參數的名稱(parameter_1_exp1
,parameter_2_exp1
等)。
從數據庫讀取/寫入的查詢現在變得稍微複雜一些(需要連接),但不再依賴於即時創建表。
讓我知道如果這不清楚,我可以提供一個潛在的數據庫圖。
非常感謝您的及時回覆。我一直在四處搜索,發現了類似的解決方案,名爲entity-attribute-value。如上所述,這將創建一個「長而瘦」的表格,並且查詢會變得有點複雜。另一個可能的解決方案是將參數配置存儲爲一個二進制對象BLOB,但是,這不會支持查詢,因此需要一些額外的代碼來遍歷二進制對象。 – Poplong
另一種選擇是以JSON對象的形式將參數存儲在字符串中。您可以使用JSON庫來幫助解析對象,這可能比直接BLOB解析更容易,但是像您提到的那樣仍然需要額外的代碼。 – Michael