或者更確切地說,積極因素是否大於消極因素?假設自動遞增主鍵是按照時間順序設計的錯誤設計?
目標是獲得N個最近的記錄。
優點:
- 不必指數created_at列
- 你的ORDER BY將使用聚集索引
缺點:
- 你依靠主鍵的時間有序性來保證開發週期的生命
想法?
或者更確切地說,積極因素是否大於消極因素?假設自動遞增主鍵是按照時間順序設計的錯誤設計?
目標是獲得N個最近的記錄。
優點:
缺點:
想法?
由於數據庫事務,多個會話可能會在不同的時間提交,您會發現它並不總是按時間排序。
另一個騙子是沒有創建於created_on
一個指標,你忘了提:
我覺得這個問題只能根據需求來回答。
雖然這是常見的做法,但有很多情況下主鍵變得無序。我經常遇到這個問題。我個人發現最好設置創建時設置的created_at列。
除非將所有插入操作序列化,否則可能無法保證自動遞增鍵的順序是按時間順序排列的。
如果您使用代理鍵來確定序列並從中驅動業務邏輯,那麼您也首先破壞了代理鍵的主要優勢。替代品應該沒有商業意義,例如,您可以在數據庫維護和模式更改期間輕鬆更新/重新分配這些值。
除了您提到的情況之外,有時在合併來自其他來源的數據時,數據可能不會按照創建的順序創建。例如,假設您的公司購買了另一家公司,並且您必須將其歷史訂單添加到您的公司。記錄可能在2007年創建,但直到2012年纔會添加到您的表格中。如果您正在查看某些對時間非常敏感的訂單,我不希望我從另一系統中轉換出來的那些與2012年剩餘時間一起顯示報告中的數據。 – HLGEM 2011-02-16 18:56:52