表命名和數據庫規範化
我正在創建一個模擬結果數據庫，並試圖以正確的方式進行。我試圖展示數據之間的關係，以確保沒有多餘的東西被扔進去。
我目前的結構是這樣的：
實驗
主鍵：SimulationID
表：
- 測量
- 採樣率
- first_draft_flow_rate
- second_draft_flow_rate
- final_flow_rate
與這些表相關的外鍵：cycle_count
每個表都包含變數的主鍵、外鍵和值。
因此，對於給定的實驗，它執行了這麼多周期（它執行的周期數因模擬而異）。我們在模擬的每個週期記錄數據。
我已經製作了一個名為
measurement,sampling_rate等的表，但不確定如何命名這些列。也應該稱為measurement,sampling_rate等嗎？或者我應該只Value用作列名？這是一個帶有範例日誌的電子表格，用於展示我正在使用的內容。所有這些數據都將歸檔在一個
SimulationID.
此外，任何關於如何最好地將數據庫設計為正常/最佳實踐的提示將不勝感激。
這不是數據庫管理，這是數據建模。非常不同的學科。
我猜你的主要實體是模擬，你列出的表格描述了它。您沒有顯示這些表格的結構或內容，因此以下內容基於猜想。
測量看起來可能是測量類型的列表：溫度、流量、每單位體積的粒子等。 SamplingRates 也看起來像有效速率的列表：1/sec、10/sec、100/sec 等。
最後有三個看起來應該是一個的表，FlowRates，這也是一個查找表。
這意味著模擬是記錄的結果，例如，以 30 毫升/秒的流量每秒 10 次的速率讀取溫度。
那準確嗎？如果是這樣，這將是一個範例：
Measurements ID Name 1 Temperature 2 Particles per ml SamplingRates ID Name Period 1 1 sec 2 10 sec FlowRates ID Rate Unit Period 1 10 ML sec 2 20 ML sec 2 30 ML sec因此，範例模擬條目將顯示測量值 1、採樣率 2 和流率 3——當然還有測量結果，可能還有執行模擬時的時間戳。
如果您可以對實驗進行簡單的語言描述，這將有很大幫助：“實驗由任意數量的模擬組成。模擬由……以特定頻率基於……的各種讀數組成。”不要考慮表格和列。假設您正在與實驗室技術人員交談。
**更新：**在設計表時（這與命名欄位有關），將實體與所有其他實體隔離通常是一個好主意——也就是說，命名應盡可能與上下文無關。這意味著如果您有一個表示實體名稱或描述的欄位，那麼請務必將這些欄位稱為“名稱”和“描述”。無論您在分散在數據庫中的表中是否有許多其他具有相同名稱的欄位。
表沒有上下文。它是建立上下文的查詢。
select s.Name as NewSite, u1.Name as Owner, u2.Name as Manager from Site s join Users u1 on u1.ID = s.OwnerID join Users u1 on u2.ID = s.MgrID where s.Created > '2015-01-01';這裡有三個表，每個表都有欄位名稱——一個表被使用兩次並不重要。在每個表中，Name表示“這是該行表示的實體的名稱”。
此查詢建立的上下文很容易辨識。它正在查看所有新創建站點的所有者和管理者，並重命名每個名稱欄位以適應上下文。不同的查詢可以並且確實在完全不同的上下文中使用這些欄位。由於設置上下文的是查詢，因此讓查詢將欄位重命名為最適合該上下文的任何內容。
不要嘗試通過命名欄位 User_ID 或 User_Name 等來強制使用表的上下文。在查詢中，欄位應該以表名或別名作為前綴，因此不會有任何混淆。
where User.Name = 'John Smith'與之比較
where User.User_Name = 'John Smith'額外的“User_”沒有添加任何有用的資訊。此外，你一定會遇到這樣的事情：
where ExtremelyLongTableName.ExtremelyLongTableName_SomewhatLongFieldName = ...我只是打字一次就累死了。此外，一些 DBMS 限制對象名稱的長度。Oracle iirc 只考慮對象名稱的前 32 個字元。在使用tablename_fieldname約定的商店中，我不止一次達到了這個限制。在這一點上，您必須使用非常混亂的縮寫。
無論如何，“最佳實踐”是一個相當主觀的概念。意見會有所不同。選擇最適合您的。