使用日期作爲Rails主記錄中的主鍵

Question

我在考慮使用date作爲主鍵而不是跟蹤應用程序的標準整數ID，但是，似乎沒有太多支持使用非整數rails文檔中的主鍵。這是不是皺起了眉頭？我該怎麼做，爲什麼我應該/不應該考慮它？

Answer 1

Rails確實支持使用自定義列作爲主鍵的id，就我所知，它可以是字符串或整數類型。現在

，你計劃使用日期類型作爲主鍵，有幾件事情需要注意：

主鍵必須具有這些特性（至少在Rails的）：

• 不能爲空
• 必須是唯一的
• 具有指數

所以做你的日期列全填寫所有這些屬性？如果沒有，那麼放棄你的計劃，否則繼續閱讀...

有很多的事情，你必須配置（不按軌道默認）使用非ID作爲主鍵：

1. 遷移文件
2. Model類
3. 路線
4. 控制器

您可以查看下面的鏈接爲comprehensiv Ë一步一步的指導： http://ruby-journal.com/how-to-override-default-primary-key-id-in-rails/

請記住，Rails的口頭禪是約定優於配置，這意味着從常規偏離你失去一些Rails所提供的優勢。如果您接受可能面臨的配置和潛在風險，至少應重新考慮使用日期作爲列類型的概念，並選擇整數或字符串。

Answer 2

您正面臨自然（數據導出）和人工（任意值）鍵的哲學問題。

如在關係理論中所闡述的，鍵與tupple（行）是包含在其中的唯一識別它的數據值的組合。例如：在發票明細行表中，發票行的自然鍵可能是與行號串聯的發票號。剩餘的數據，產品，數量，單價等通過該密鑰唯一訪問。

另一種方法是簡單地分配序列號到行和地點在一個特定領域，通常命名爲ID，這無關與包含在列中的數據。

哪種方法更優越？那麼，這取決於很多事情。但讓我們看看給出的例子 - 發票行。說它是發票20，並且有10行。我們可以想象一個鍵集看起來像這樣：000020000001到000020000010.那麼，當我們刪除第6行時會發生什麼？具有密鑰000020000006的行被刪除。

讓我們考慮發票的行號印在上面，以便將來的客戶查詢可以明確地提及。現在，當我們打印發票時會發生什麼？當我們打印發票時，我們是否按照線序排列了差距，還是將它關閉？如果我們離開這個差距，那麼我們客戶發票上的最後一個發票行將顯示10.這意味着臨時讀者在發票上有10行。但第6行不存在，因此發票上只有9行。

另一種方法是在刪除之後重新編號其餘行，以使前面的第7行變成第6行，依此類推。但是，這會更改這三行中的鍵值，這意味着對這些行的所有其他引用也必須更新。這將在任何一種現實生活系統中造成相當大的開銷，並且可能會是一個不斷的錯誤來源。

使用人工鍵id不需要在數據庫外部可見。由於這一次分配它不需要改變。因此，如果發票行的關鍵字是任意值，則可以按照人們認爲合適的方式自由更新和重新編號發票行，例如按照擴展值的降序排序，並且所有內部參考不受影響。人們也可以改變發票號碼，比如在後退訂單的情況下。

在關係數據庫設計中，經常出現的問題還沒有完全規範化。或者要獲得一個天生的獨特密鑰，就需要包含如此多的數據，以至於樹脂本身成爲關鍵。在這些情況下，自然鍵或者不能提供必要的獨特品質，或者它們的存在使得更新花斑成本過高。

在實踐中，人造鑰匙已被證明既提供了保證的唯一密鑰，又允許與自然鑰匙相比修改所包含數據的最大靈活性。由於這些原因，人造鑰匙被廣泛使用，並被許多人認爲是上乘或至少是實用的選擇。

但是，沒有絕對的。有很多情況下，一個自然鍵是完全有意義的（例如代碼表），並且使用人工標識是毫無意義的。無論如何，根據我的經驗，如果一個設計使用了人造鑰匙，那麼它們將在任何地方使用。

這是RoR採取的方法，並且爲了實際目的，它最有意義。您可以重寫任意鍵約定。 AR文檔提供瞭如何這樣做的更充分的解釋。在某些項目中，我已經覆蓋了RoR主鍵，但是我從來沒有發現一個真正值得努力的場合。

最後一個註釋。許多人將關係密鑰與索引混淆。關鍵僅僅是關係系統鏈接集合成員的手段。它不一定是從數據庫中檢索數據的首選方法。爲此目的，我們使用索引，然後只有維護索引的成本低於通過簡單串行搜索才能提高檢索速度所獲得的收益。索引值並不一定是唯一的，但如果願意的話，索引值也可以作爲約束條件。