儲存各種類型的參數
我是一名（貧窮的、年輕的）科學家，致力於開發數據庫以擴大項目規模。我正在嘗試使用 MySQL，到目前為止，我的經歷非常令人鼓舞，但我仍然是新手，可能是從一個不同尋常的角度來做這件事的。
下面是我的模式相關部分的圖表，因為我現在已經對其進行了建模。在這一點上，這些欄位基本上是佔位符，但總的來說，我想為數據庫中幾乎每個獨特元素的文件留出空間（可能不是為了工作，但我離題了）。我要追求的有幾個品質：
- 有效參數取決於算法，我們可能隨時添加新算法。我希望能夠註冊一個新算法，並將其與特定參數相關聯。
- 因為新算法可能需要新參數，所以我也應該能夠註冊新參數。
- 一個特定的實驗將使用一種算法。作業是實驗/算法的獨特參數化。通過實驗和算法的關係，我可以驗證與特定作業一起送出的參數。
鑑於此架構，我的困惑點是如何儲存特定作業的參數值。現在，作為佔位符，我
values在 table 中有一個列job_has_parameter，但這不起作用。有些參數是整數，有些是雙精度數，還有一些是字元串。一些算法甚至可能將列表作為參數……但我現在願意對此進行抨擊。無論如何，單列value是行不通的。這種模式是否有意義？如果它確實有意義，一般來說，處理儲存參數值的合理方法是什麼？我歡迎批評；我並不認為我在這裡走在正確的軌道上，但這是一種努力。
**編輯：**我認為這個模式無意中採用了實體屬性值樣式。我讀到這是一件壞事。https://www.simple-talk.com/sql/t-sql-programming/avoiding-the-eav-of-destruction/也許有人可以幫助我走上更好的道路？
在 Job_Has_Parameter 表中添加一個額外的列怎麼樣？
添加一個名為 DataType 的列並儲存文本包含的值的類型。
在使用值時，您可能必須使用 case 語句和 cast/convert 函式的組合。
您可以將其帶到下一步並添加一個名為 datatype 的表，並使用這個新列創建一個外部。
總的來說，我認為你的模型非常好。我要指出的是，您為介紹數據庫而選擇的項目是一個相當困難的項目。不要氣餒，但不要指望它會一舉到位。
本質上，數據庫中參數化的算法都將由某種主算法處理，該算法通過讀取與該作業相關的參數並相應地調整事物來適應手頭的工作。好東西，如果你能把它拉下來。
現在回到你問的問題的細節：如何容納不同類型的參數。這是類型和子類型的經典案例，儘管我更喜歡術語類和子類。這個問題在關係數據庫設計中反復出現，通常以不同的形式出現。關於子類的問題，這裡已經提出並回答了數十個問題。這些問題表面上是完全不同的，但它們都歸結為同一件事。
一個問題是關係模型不適合繼承的概念，而繼承是表達類子類關係的優雅方式。有一些眾所周知的解決方法，其中之一可能適合您的情況。
對以下流行語進行網路搜尋：
Simple table inheritance Class table inheritance Postgres Table Inheritance您會發現大量關於如何設計擷取繼承要素的表的文章。但是，使用這些表需要一些仔細的程式。
在你的情況下，這是我要走的路：
從 job-has-parameters 表中刪除值欄位。
為不同類型的參數提供單獨的表格。我將把我的討論限制在兩種類型，文本和數字。但你明白了。在 job-has-text-parameters 表中，您有 jobId 和 ParameterId 以及 value。值當然是文本類型。JobId 和 ParameterId 合起來就是這個表的主鍵。
同樣，您有 job-has-number-parameters 表，您有相同的三個欄位，除了該值現在是 number 類型。您可能還需要參數表中的類型欄位來指示新作業使用該參數時該參數必須採用的類型。
不要太擔心您的設計和 EAV 之間的重疊。基本上，您的設計比經典的關係數據庫學習項目所教授的更具動態性。大多數對 EAV 的批評來自於它試圖完全動態化，從而使數據定義對不斷變化的主題模型保持不變。這樣做的缺點是它使數據很難轉化為有用的資訊。
但在您的情況下，參數的動態質量不僅僅是設計選擇，而是主題本身的基礎，除非我錯過了我的猜測。
祝你好運。