什麼是更好的：使「日期」複合屬性或原子？

Question

在我需要將整個日期（即日，月，年）作爲整體使用並且從不需要提取日期的日期，月份或年份部分的情況下，在我的數據庫應用程序中程序，什麼是最好的做法：

1. 製作日期原子屬性
2. 製作日期的複合屬性（由日，月和年）

編輯： - 這個問題可以概括爲：

是在可能的情況下製作複合屬性是一種很好的做法，即使我們只需要處理整個屬性？

Answer 1

其實，具體問題和一般問題是顯着不同的，因爲具體問題是指日期。

對於日期，組件元素並不是您正在建模的東西的一部分 - 歷史上的一天 - 它們是您正在建模的東西的表示的一部分 - 日曆中的一天你（和你的國家的大多數人）使用。

對於日期我會說最好將它存儲在單個日期類型字段中。

對於廣義問題，我通常會單獨存儲它們。如果你確信你只需要整體處理它，那麼你可以使用單個字段。如果您認爲有可能需要將組件分開使用（即使僅用於驗證），然後將它們分開存儲。

---

具體日期，大多數現代數據庫作爲單個日期值有效地存儲和操作日期。即使在您想要訪問日期的單個組件的情況下，我也建議您使用單個日期字段。

最終你幾乎不可避免地需要做某種日期算術，而且大多數數據庫系統和編程語言都提供了一些操作日期的功能。這些將更容易與單個日期變量一起使用。

使用日期，整個複合日期標識出您正在識別的主要現實世界事物。

日/月/年是單一事物的屬性，但僅限於描述它的特定方式 - 西方日曆。

但是，同一天可以用許多不同的方式表示 - unix時代，公曆，農曆，在某些日曆中，我們處於完全不同的一年。所有這些表示可以不同，但​​是指的是同一個人的真實世界日。

因此，從建模的角度來看，從數​​據庫/編程效率的角度來看，對於日期，儘可能將它們存儲在單個字段中。

---

對於泛化，這是一個不同的問題。

根據經驗，我會將它們作爲單獨的組件存儲。如果你真的確定你永遠不想訪問組件信息，那麼是的，一個領域會沒事的。只要你是對的。但是，如果甚至有能力打破這些信息，我就會從一開始就將它們分開。

將字段連接在一起比將字段與組件字符串分開要容易得多。這既來自程序/算法觀點，也來自計算資源觀點。

我在編程中遇到的一些最痛苦的問題是試圖將單個字段分解爲組件元素。他們最初被存儲爲一個元素，當業務發生變化時足以認識到他們需要這些組件......它已經成爲一個體面的挑戰。

大多數複合數據項不像日期。如果某個日期是單個項目，那麼有時候（通常在西方世界中）以日 - 月 - 年組合表示，大多數組合數據元素實際上代表了幾個具體項目，並且只有這些項目的組合才真正唯一地表示一件特別的事情。

例如銀行賬戶號碼（在新西蘭，無論如何）是有點像這樣：

• 銀行 - 2或3個數字
• 分支號 - 第4到6位數字
• 賬戶/客戶號碼 - 8位數字
• 賬戶類型號碼 - 2位或3位數字。

這些元素中的每一個代表一個現實世界的事物，但它們共同確定我的賬戶。

您可以將它們存儲爲單個字段，並且它在很大程度上可以工作。如果您需要，您可能會決定使用連字符分隔元素。

如果你真的不需要訪問某個特定的信息，那麼你將它作爲一個複合存儲是很好的。但如果3年下來一家銀行決定收取更高的費率，或需要不同的處理;或者如果您想進行區域性推廣並將其鍵入分行號碼，現在您有不同的挑戰，並且您需要提取該信息。我們選擇連字符作爲分隔符，因此您必須將每行解析到組件元素中才能找到它們。 （現在磁盤價格相當便宜，所以如果你這樣做，你會存儲它們，在過去它很昂貴，所以你必須決定是否支付存儲，或支付每次重新計算）。個人而言，在銀行賬戶的情況下（也可能是我能想到的大多數其他例子），我會將它們分開存儲，並可能設置參考表以允許驗證發生（例如，您不能輸入一家我們不知道的銀行）。