我應該使用 int 列來表示日期嗎？
我正在設計一個 Invoice 表，並希望在決定幾個索引和主鍵方面得到幫助。
- 對於主鍵 - 使用 GUID 對我來說可能是個好主意，但這是否意味著子表也需要將這個 GUID 作為外鍵？
- 始終使用日期範圍在創建日期過濾發票。因此，我計劃有一個額外的 int 列，而不是 datetime 列，它只包含像“20160101”這樣的日期資訊，因為我認為比較 int 比 datetime 快得多，並且對我有利。由於創建時間會越來越長，所以我也打算在這個專欄應用集群索引。這是一個好主意嗎？
- 也可以根據客戶查詢發票，我應該在CustomerID上放置另一個索引還是與日期列組合？
對問題標題的簡短回答：不。您為什麼要失去將日期視為日期的能力。對於排序、日期功能等非常重要。
至少有一些想法可以讓您開始，不確定在回答時使用哪個 DBMS，根據我對 SQL Server 的經驗進行回答：
1.) GUID 作為主鍵通常不是一個好主意。尤其是在 SQL Server 中。整數主鍵有什麼問題？是的，無論您的主鍵是什麼，都將成為子表中的外鍵，因此它很大並且可能沒有必要。
2.) 我會使用正常的日期時間列。性能方面，如果你的索引很好，你不應該注意到這裡有什麼不同。日期時間列作為日期更通用。您可以提出對具有內置日期時間函式的 INT 列無法輕鬆提出的問題。如果您不需要時間並且您使用的 DBMS 或版本只有 DATE，您可以使用該數據類型。
3.) 是的。特別是如果 CustomerID 是客戶表的外鍵。好索引。是否需要在 CustomerID AND Date 列上創建索引取決於查詢的通常外觀。如果您經常查詢加入客戶並指定日期範圍，您可能會發現有日期是有益的。您可能會發現包含一些其他列以覆蓋其他查詢作為鍵或包含列的一部分是有益的。不過，這實際上取決於您的查詢和數據。
就日期列上的分群而言。這很難。如果這是一個倉庫中的事實表，並且每個查詢總是在一個日期範圍內，那麼那裡有一些好處。如果這是一個可操作的發票表，我想您的應用程序也會以其他方式加入發票。我還想像通過儲存在其他表等中的發票 ID 來查詢發票。所以我認為沒有足夠的數據來確定聚集鍵。我所在的學校更喜歡 OLTP 表的簡單代理鍵。一個 InvoiceID INT（或 BIGINT，如果你真的想吹掉一個 INT）設置為一個標識列，所以它總是增加並避免頁面拆分。但我不知道這裡是否有明確的錯誤答案（當然有很多，但你沒有提出任何一個）